Fixed Periodic Schedule — Requirements v2.2-rc26 min read

Must conform to the Request JWT requirements — correct aud, signing algorithm (PS256), and expiry window.

Must be included in the POST body (client_assertion_type: urn:ietf:params:oauth:client-assertion-type:jwt-bearer). Authenticates the TPP application — see Client Assertion.

Must be payments openid. If consent.Permissions includes any of ReadAccountsBasic, ReadAccountsDetail, ReadBalances, or ReadPartyIdentity, must be accounts payments openid — see Account Permissions in a Payment Consent.

Must be urn:openfinanceuae:service-initiation-consent:v2.2.

The consent version in authorization_details[0].type (e.g. urn:openfinanceuae:service-initiation-consent:v2.2) restricts the version of the Payment Initiation endpoints the consent can be used to call (specified in the path, e.g. /open-finance/payment/v2.2/payments). It MUST resolve to an ApiVersion the LFI has published in the Trust Framework for the Payment Initiation API family.

The request must conform exactly to the POST /par OpenAPI schema. No additional or undocumented parameters are permitted.

The decrypted PII payload must conform exactly to the PII schema. No additional or undocumented parameters are permitted.

The Risk block must be fully populated — every field that is known or derivable from the TPP's system must be included. See Risk.

If provided, must reference a valid UAE IBAN held at the LFI and reachable through this API Hub. The account must be in a state that permits payment initiation (e.g. not blocked, dormant, or closed).

Required. Must contain exactly one creditor entry. The Creditor must be a valid UAE domestic creditor — the account must be reachable on a supported UAE domestic rail (AANI or UAEFTS) and, where the LFI can determine the state of the receiving account, in a state able to receive payments. Mandatory fields, IBAN, and BIC derivation rules apply — see creditor field validation requirements.

Where both Initiation.DebtorAccount and Initiation.Creditor are provided, Initiation.DebtorAccount.Identification MUST NOT be the same as the CreditorAccount.Identification of any entry in Initiation.Creditor. A payment MUST NOT be instructed from and to the same account. Payments between two different accounts held by the same User are not affected.

Must be false or not provided (Delegated SCA is not permitted for this payment type).

Must be "FixedPeriodicSchedule". SinglePayment and FilePayment must not be present.

Required. Defines the exact fixed amount for each payment within a period.

Must be AED.

Required. Defines the period boundary (e.g. Week, Month).

Required. The date from which each period is counted. Must not be in the past. Must not be after consent.ExpirationDateTime.

Only 1 payment is allowed per period. Always enforced.

Required. Defines the total number of payments permitted across the lifetime of the consent.

If set, defines the maximum total value of all payments permitted across the lifetime of the consent.

If set, MaximumCumulativeValueOfPayments.Currency must be AED.

The LFI must advertise Fixed Periodic Schedule as supported via ApiMetadata.FixedPeriodicSchedule.Supported on its authorisation server entry in the Trust Framework. If the payment type is not supported, the consent validation will fail.

If provided, must reference a previous consent belonging to the same end user. If the original consent in the chain already had a BaseConsentId, the TPP must reuse that same BaseConsentId rather than the immediate prior ConsentId.

Optional; default is false. Omitting or setting to false asserts that the TPP supports the multi-authorization flow — the consent may remain pending while additional authorizers approve before reaching Authorized. Setting to true requests that only accounts solely authorizable by the authenticated customer be offered. The LFI must not reject the consent based on its own platform capability — this is a TPP-side assertion. See Multi-Authorization.

If provided, must be more than 15 minutes in the future. Must not be after consent.ExpirationDateTime.

If the TPP wishes to cap how long the User has to authorize the consent, it must do so with consent.AuthorizationExpirationDateTime, which must be more than 15 minutes in the future and must not be after consent.ExpirationDateTime.

Must be more than 15 minutes in the future. Must be less than one year in the future.

If ReadBalances is included, at least one of ReadAccountsBasic or ReadAccountsDetail must also be present.

Must not be present. Domestic payments are denominated in AED only; CurrencyRequest is for non-local currency and international transfers.

If provided, must be a recognised AANI purpose code.

The TPP SHOULD set the most meaningful Structured Reference for the consent. Where the reference is not dictated by the requirements of the payments use case, to a maximum of 35 characters: the User-provided free-text reference (to a maximum of 22 characters); a dash (-) separator; the Creditor LFI bank name (to a maximum of 8 characters) where the payment is not initiated on behalf of a Merchant; a dash; optionally the Merchant name (to a maximum of 8 characters) where the TPP initiates on behalf of a Merchant, followed by a dash; and the TPP name, as found in the Trust Framework or a recognisable alternative.

Should be included. Should be a valid UUID (RFC 4122). An invalid value will not cause a failure but tracing will not be possible.

Must contain a valid Bearer access token issued with the payments openid scope (or accounts payments openid where ReadAccountsBasic, ReadAccountsDetail, ReadBalances or ReadPartyIdentity was included on the consent — see Account Permissions in a Payment Consent). The consent bound to the token must be in Authorized status and the ExpirationDateTime of the Consent must be in the future.

The version in the request URL path (e.g. v2.2 in /open-finance/service-initiation/v2.2/payments) must match the version in the consent's authorization_details[0].type (urn:openfinanceuae:service-initiation-consent:v2.2).

Must match the ConsentId bound to the access token. The Consent must be in Authorized status and the ExpirationDateTime of the Consent must be in the future.

Must exactly match consent.ControlParameters.ConsentSchedule.MultiPayment.PeriodicSchedule.Amount.Amount.

Must exactly match consent.ControlParameters.ConsentSchedule.MultiPayment.PeriodicSchedule.Amount.Currency.

The payment must not cause the count of payments over the lifetime of the consent to exceed MaximumCumulativeNumberOfPayments.

If set on the consent, the payment must not cause the value of payments over the lifetime of the consent to exceed MaximumCumulativeValueOfPayments.Amount.

Can differ from consent.PaymentPurposeCode. If provided, must be a recognised AANI purpose code.

Can differ from consent.DebtorReference — the TPP MAY set a per-payment Debtor Reference rather than reuse the consent value. Where it is not dictated by the requirements of the payments use case, it SHOULD still follow the Structured Reference convention described under Consent Creation.

Only one payment is permitted per period. A second POST /payments within the same period will be rejected.

The request must conform exactly to the POST /payments OpenAPI schema. No additional or undocumented parameters are permitted.

The decrypted PII payload must conform exactly to the PII schema. No additional or undocumented parameters are permitted.

The Risk block must be fully populated — every field that is known or derivable from the TPP's system must be included. See Risk.

Required for a retail User. This consent is long-lived, so the TPP must capture the User's Emirates ID and send it on every POST /payments, matching ^784-?[0-9]{4}-?[0-9]{7}-?[0-9]{1}$. The LFI compares it with the Emirates ID of the PSU behind the consent, and may reject the payment with 400 Consent.BusinessRuleViolation when it is missing or does not match. See Emirates ID on Long-Lived Payments.

Initiation.Creditor[] had exactly 1 entry at consent time. The submitted creditor must exactly match that consent-time entry. See Creditor.

The TPP MUST NOT submit a payment where Initiation.CreditorAccount.Identification in the PersonalIdentifiableInformation is the same as the debtor account of the consent, where the debtor account is known to the TPP — for example, because it was supplied in Initiation.DebtorAccount at consent creation, or read using account permissions included on the consent (see Account Permissions in a Payment Consent). A payment MUST NOT be instructed from and to the same account.

Should be included. Should be a valid UUID (RFC 4122). An invalid value will not cause a failure but tracing will not be possible.

Must be included. Must be a stable, unique value per payment attempt — the same key must be reused on retries of the same payment.

Must be sent when the customer is authenticated at the time of the call. Must be a valid HTTP-date (RFC 7231), e.g. Tue, 11 Sep 2012 19:43:31 UTC.

Must be sent when the customer is actively present at the time of the call. Must be a valid IPv4 or IPv6 address.

Should be sent when the customer is actively present. Should reflect the user-agent of the customer's browser or device.