Fixed Periodic Schedule - User Experience v2.1

When a customer is redirected to you to authorize a Fixed Periodic Schedule payment consent through Open Finance, you must present an Authorization Page that clearly explains the payment the customer is authorizing — that recurring payments of a fixed amount will be made at a set frequency. The page must collect the customer's explicit and informed consent, and it must accurately reflect the key details of the consent (payee, amount per payment, payment frequency, etc.)

The examples and interactive wireframes provided below define the expected structure, content, and behavior of the Authorization Page and must be followed.

While you may adapt visual elements such as color palette, fonts, and styling, you must not alter the meaning, clarity, or completeness of the payment information shown. The representation of AlTareq (including logos, naming, and action buttons) must be preserved at all times. The customer must be able to clearly understand what payment they are authorizing and that the authorization is part of the AlTareq ecosystem.

Your Authorization Page must be submitted as part of CX certification prior to production. Any material changes to a production Authorization Page must also be resubmitted 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

TypeCurrent AccountSavings

IBAN

Currency

Balance (AED)

Overdraft (AED)

TypeCurrent AccountSavings

IBAN

Currency

Balance (AED)

2 / 5

Live UI Preview

Changes made above are immediately reflected in both panels.

TPP · Consent Page

TPP

1

Consent

2

Authorize

3

Complete

Permission to make payment(s)

To make payments from your bank, we need your permission to securely initiate the payment(s)

Payment setup

Payment to

Reference

Payment Purpose

Unknown code

Payment rules

Amount

First Payment Date

Invalid Date

Payments Repeat every

Expiry Date

Invalid Date

From account

Bank

[Your LFI]

To account

Terms

Authorize using AlTareq

We will securely transfer you to [YOUR LFI] to authorize and set up the payment

LFI · Authorisation Page

LFI

Consent

2

Authorize

3

Complete

Flexi-Pay Setup

[TPP trading name] needs your permission to make payments from your account under the rules below. They will process payments in line with your agreement and are responsible for selecting the beneficiaries.

Payment Details

Payment Reference

Payment Purpose

Unknown code

Payment rules

Amount

First Payment Date

Invalid Date

Payments Repeat every

Stop Payments on

Invalid Date

Please select the account to pay from

Current Account

AE07 0331 2345 6789 0123 456

Balance

5000

Overdraft

1500

Savings

AE07 0331 2345 6789 0123 457

Balance

25000

Authorize using AlTareq

Cancel

Authentication

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 per-period limits that reset each period.

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

Field	UI Label	Behaviour
MaximumCumulativeNumberOfPayments	Total Number of Payments allowed	The maximum number of individual payments that can be made across the entire consent. Only shown when provided.
MaximumCumulativeValueOfPayments	Total Value allowed	The maximum total amount that can be paid across the entire consent. Only shown when provided.

Per-period limits (set at ControlParameters.ConsentSchedule.MultiPayment.PeriodicSchedule):

Field	UI Label	Behaviour
Amount	Per Payment	The amount allowed for a single payment. Always shown.
(implicit)	Payments per Period	Only 1 payment is allowed per period. Always shown.

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 — row not shown when parameter is absent:

Payment rules
───────────────────────────────────────────
Amount                              AED 200
───────────────────────────────────────────

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

Payment rules
───────────────────────────────────────────
Amount                              AED 200
Total Number of Payments 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.Creditor	LFI Authorisation Page Behaviour
1 creditor	The single payee's name and account details are displayed under "Who you're paying". (See Example 1)
2–10 defined creditors	❌ Not Supported
Undefined (absent or empty)	❌ Not Supported

Permissions and Data Access

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

Permissions	Text shown to user on Consent Page
ReadAccountsBasic	You also grant us permission to access your account details before making the payment.
ReadAccountsDetail	You also grant us permission to access your account details before making the payment.
ReadRefundAccount	You also grant us permission to access your account details in order to process a refund.
ReadAccountsBasicReadAccountsDetail	You also grant us permission to access your account details before making the payment.
ReadAccountsBasicReadBalances	You also grant us permission to access your account details and balance before making the payment.
ReadAccountsBasicReadRefundAccount	You also grant us permission to access your account details before making the payment, as well as to process refunds.
ReadAccountsDetailReadBalances	You also grant us permission to access your account details and balance before making the payment.
ReadAccountsDetailReadRefundAccount	You also grant us permission to access your account details before making the payment, as well as to process refunds.
ReadAccountsBasicReadAccountsDetailReadBalances	You also grant us permission to access your account details and balance before making the payment.
ReadAccountsBasicReadAccountsDetailReadRefundAccount	You also grant us permission to access your account details before making the payment, as well as to process refunds.
ReadAccountsBasicReadBalancesReadRefundAccount	You also grant us permission to access your account details and balance before making the payment, as well as to process refunds.
ReadAccountsDetailReadBalancesReadRefundAccount	You also grant us permission to access your account details and balance before making the payment, as well as to process refunds.
ReadAccountsBasicReadAccountsDetailReadBalancesReadRefundAccount	You 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

Click to expand

Example 2 - Account Selected at LFI

Click to expand

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

Click to expand