Validate · Enforce · Trust

Fixed On Demand — Requirements v2.16 min read

The Consent requirements and the User Journeys for this payment type also apply and must be adhered to.

The tables below list the validation rules that apply to Fixed On Demand. The Validated by column indicates where each rule is enforced. All requests require an active Trust Framework application with the BSIP role, a valid transport certificate presented on every request via mTLS, and an active signing key for JWT signing.

02 Section

Authorization — Account Selection

#
Field
Rule
Validated by
1
Initiation.DebtorAccount ownership
If Initiation.DebtorAccount was provided on the consent and the authenticated customer does not hold that account, the consent will be set to Rejected with error: invalid_request and error_description: user_does_not_own_debtor_account.
LFI
2
consent.IsSingleAuthorization
If true, only accounts that the authenticated customer can solely authorize (no subsequent approvers required) may be offered and selected. If false or not provided (default), accounts where the customer is one of multiple required authorizers may also be offered; subsequent authorizers must then approve the consent before the consent reaches Authorized status and any payment can be executed. See Multi-Authorization.
LFI
3
Eligible payment accounts
If the authenticated customer does not hold any account eligible to initiate a payment under this consent, the consent will be set to Rejected with error: invalid_request and error_description: user_lacks_eligible_accounts. The eligible set is constrained by consent.IsSingleAuthorization as described above.
LFI
03 Endpoint

Payment Initiation

POST/payments
#
Field
Rule
Validated by
1
Authorization
Must contain a valid Bearer access token issued with the payments openid scope (or accounts payments openid where account permissions were 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.
API Hub
2
URL version
The version in the request URL path (e.g. v2.1 in /open-finance/service-initiation/v2.1/payments) must match the version in the consent's authorization_details[0].type (urn:openfinanceuae:service-initiation-consent:v2.1).
API Hub
3
Data.ConsentId
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.
API Hub
4
Data.Instruction.Amount.Amount
Must exactly match consent.ControlParameters.ConsentSchedule.MultiPayment.PeriodicSchedule.Amount.Amount.
API Hub
5
Data.Instruction.Amount.Currency
Must exactly match consent.ControlParameters.ConsentSchedule.MultiPayment.PeriodicSchedule.Amount.Currency.
API Hub
6
MaximumCumulativeNumberOfPaymentsPerPeriod
If set on the consent, the payment must not cause the count of payments in the current period to exceed MaximumCumulativeNumberOfPaymentsPerPeriod.
API Hub
7
MaximumCumulativeValueOfPaymentsPerPeriod
If set on the consent, the payment must not cause the value of payments in the current period to exceed MaximumCumulativeValueOfPaymentsPerPeriod.Amount.
API Hub
8
MaximumCumulativeNumberOfPayments
If set on the consent, the payment must not cause the count of payments over the lifetime of the consent to exceed MaximumCumulativeNumberOfPayments.
API Hub
9
MaximumCumulativeValueOfPayments
If set on the consent, the payment must not cause the value of payments over the lifetime of the consent to exceed MaximumCumulativeValueOfPayments.Amount.
API Hub
10
Data.PaymentPurposeCode
Can differ from consent.PaymentPurposeCode. If provided, must be a recognised AANI purpose code.
API Hub
11
OpenAPI schema
The request must conform exactly to the POST /payments OpenAPI schema. No additional or undocumented parameters are permitted.
API Hub
12
PersonalIdentifiableInformation
The decrypted PII payload must conform exactly to the PII schema. No additional or undocumented parameters are permitted.
LFI
13
PersonalIdentifiableInformation.Risk
The Risk block must be fully populated — every field that is known or derivable from the TPP's system must be included. See Risk.
Monitored by Nebras
14
PersonalIdentifiableInformation (Creditor)
Initiation.Creditor[] had exactly 1 entry at consent time. The submitted creditor must exactly match that consent-time entry. See Creditor.
LFI
15
x-fapi-interaction-id
Should be included. Should be a valid UUID (RFC 4122). An invalid value will not cause a failure but tracing will not be possible.
N/A
16
x-idempotency-key
Must be included. Must be a stable, unique value per payment attempt — the same key must be reused on retries of the same payment.
API Hub
17
x-fapi-auth-date
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.
TPP
18
x-fapi-customer-ip-address
Must be sent when the customer is actively present at the time of the call. Must be a valid IPv4 or IPv6 address.
TPP
19
x-customer-user-agent
Should be sent when the customer is actively present. Should reflect the user-agent of the customer's browser or device.
TPP