Skip to content

Fixed Defined Schedule - User Experience v2.1

Before a customer authorises a Fixed Defined Schedule payment consent through Open Finance, you must present a Consent Page that clearly explains that you are seeking permission to make a pre-defined series of payments, each on a specific date for a fixed amount. This page must accurately reflect the key details of the consent (payee, the complete list of scheduled payment dates and the fixed amount for each, etc.) The examples and interactive wireframes below define the expected structure, content, and behaviour of the Consent Page and must be followed.

While you may adapt visual elements such as colour palette, fonts, and styling, you must not alter the meaning, clarity, or completeness of the payment information shown, and the representation of AlTareq (including logos, naming, and action buttons) must be preserved. The customer must always be able to clearly understand what payment they are consenting to and that it is part of the AlTareq ecosystem. Your Consent Page must be submitted as part of CX certification prior to production, and any material changes to a production Consent Page must be re-submitted for review and approval.

Interactive Demo

Customise the request body fields below and watch the Consent and Authorisation page previews update live.

domestic_payment_piiConsent Body (AEDomesticPaymentPII)
View Consent endpoint ↗
consentBodyAEPaymentConsentResponse
View Consent endpoint ↗

Configure the mock accounts the authenticated user holds at their bank. The Authorisation Page will offer these accounts when the user picks a debtor account, or validate the Initiation.DebtorAccount against them when one is pre-selected by the TPP.

Simulated User AccountsAccounts the authenticated user holds at their bank

Live UI Preview

Changes made above are immediately reflected in both panels.

UI Behaviour Driven by API Fields

Debtor Account Selection

The presence or absence of Initiation.DebtorAccount in domestic_payment_pii determines whether the user selects their account at the LFI or if it is pre-selected by the TPP.

TIP

Passing a DebtorAccount reduces friction for users who have already selected their account within the TPP's own interface, but removes the user's ability to choose a different account at the LFI.

Payment Control Parameters

Control parameters define the spending rules for the consent and are displayed in the Payment rules card on both the TPP Consent Page and the LFI Authorisation Page.

There are two groups of control parameters: overall limits that apply across the full lifetime of the consent, and the payment schedule that defines each individual payment.

Overall limits (set at ControlParameters.ConsentSchedule.MultiPayment):

FieldUI LabelBehaviour
MaximumCumulativeNumberOfPaymentsTotal Number of Payments allowedThe maximum number of individual payments that can be made across the entire consent. Only shown when provided.
MaximumCumulativeValueOfPaymentsTotal Value allowedThe maximum total amount that can be paid across the entire consent. Only shown when provided.

Payment schedule (set at ControlParameters.ConsentSchedule.MultiPayment.PeriodicSchedule.Schedule):

Unlike periodic schedule types, a Defined Schedule specifies each payment individually. Each entry in the Schedule array defines exactly one payment:

FieldUI LabelBehaviour
PaymentExecutionDateDateThe specific date on which this payment may be executed. Each date must be unique across the schedule.
AmountPer PaymentThe amount allowed for a single payment. Always shown.
(implicit)Payments per DateOnly 1 payment is allowed per PaymentExecutionDate. Always enforced.

Each schedule entry is shown as a row in the Payment schedule section of the UI, displaying the date on the left and the maximum amount on the right.

TIP

If an optional parameter is not provided in the API request, it must be omitted entirely from the User Experience — it must not be displayed as null or 0.

Correct — optional row not shown when parameter is absent:

Payment rules

Payment schedule
───────────────────────────────────────────
1 Aug 2026                         AED 500
2 Sep 2026                       AED 1,200
11 Oct 2026                      AED 1,300

Total Number of Payments allowed         3
───────────────────────────────────────────

Incorrect — optional row shown with a null or zero value:

Payment rules
───────────────────────────────────────────
1 Aug 2026                         AED 500
2 Sep 2026                       AED 1,200
11 Oct 2026                      AED 1,300

Total Number of Payments allowed         3
Total Value allowed                      0
───────────────────────────────────────────

Creditor Configuration

The presence or absence of creditors in Initiation.Creditor in domestic_payment_pii determines how the LFI presents payment recipient information to the user.

Initiation.CreditorLFI Authorisation Page Behaviour
1 creditorThe single payee's name and account details are displayed under "Who you're paying". (See Example 1)
2–10 defined creditorsNot Supported
Undefined (absent or empty)Not Supported

Permissions and Data Access

The table below describes the text shown to users on the Consent Page.

PermissionsText shown to user on Consent Page
ReadAccountsBasicYou also grant us permission to access your account details before making the payment.
ReadAccountsDetailYou also grant us permission to access your account details before making the payment.
ReadRefundAccountYou also grant us permission to access your account details in order to process a refund.
ReadAccountsBasicReadAccountsDetailYou also grant us permission to access your account details before making the payment.
ReadAccountsBasicReadBalancesYou also grant us permission to access your account details and balance before making the payment.
ReadAccountsBasicReadRefundAccountYou also grant us permission to access your account details before making the payment, as well as to process refunds.
ReadAccountsDetailReadBalancesYou also grant us permission to access your account details and balance before making the payment.
ReadAccountsDetailReadRefundAccountYou also grant us permission to access your account details before making the payment, as well as to process refunds.
ReadAccountsBasicReadAccountsDetailReadBalancesYou also grant us permission to access your account details and balance before making the payment.
ReadAccountsBasicReadAccountsDetailReadRefundAccountYou also grant us permission to access your account details before making the payment, as well as to process refunds.
ReadAccountsBasicReadBalancesReadRefundAccountYou also grant us permission to access your account details and balance before making the payment, as well as to process refunds.
ReadAccountsDetailReadBalancesReadRefundAccountYou also grant us permission to access your account details and balance before making the payment, as well as to process refunds.
ReadAccountsBasicReadAccountsDetailReadBalancesReadRefundAccountYou also grant us permission to access your account details and balance before making the payment, as well as to process refunds.

Example User Journeys

Example 1 - Account Selected at TPP

fixed-defined-schedule
Click to expand

Example 2 - Account Selected at LFI

fixed-defined-schedule
Click to expand

Example 3 - Account Selected at LFI (Less Control Parameters)

fixed-defined-schedule
Click to expand

Example 4 - Account Selected at LFI (Large Schedule)

fixed-defined-schedule
Click to expand