Build your submission
Complete each step, attach your evidence, and download a ZIP to attach to your LFI Functional Certification Evidence Service Desk ticket. New here? Read what Functional Certification involves first.
Your details
Your organisation and name are taken from your Sandbox Trust Framework session — the same sign-in used across the portal. Sign in so your submission is attributed to your LFI.
Scope & rails
Choose the standards version and segments, declare the rails your LFI supports for Single Instant Payment, and state the payment limit you apply. Each rail you declare is evidenced against its terminal status on the next step.
Select every execution mode your LFI supports for Single Instant Payment. The terminal Open Finance status each reaches is fixed by the Payment Status rules.
The maximum amount a single payment can take through Open Finance on your LFI. This MUST NOT be more restrictive than your other digital channels.
Evidence
Attach the evidence below. All evidence must come from the AlTareq Model Bank sandbox.
Core payment execution
Terminal status per supported rail
You haven’t declared any rails yet. .
Creditor validation & Risk handling
The Creditor account arrives inside the encrypted PersonalIdentifiableInformation, so evidence decrypting it and validating the creditor. The Risk object (AERisk) is cleartext — evidence that it is received and used in your fraud/screening.
Account & balance reads before the payment
Evidence a payment consent carrying ReadAccountsBasic / ReadAccountsDetail and ReadBalances — a successful account read and balance read before a successful payment. Account reads are served from https://rs1.LFICODE.apihub.openfinance.ae/open-finance/account-information/v2.1.
Refund-account read after the payment
Evidence a payment consent carrying ReadRefundAccount — a successful refund-account read after a successful payment.
Payment authorisation screen
The customer authorises the payment consent on your own authorisation page, so these screenshots come from the LFI side: the debtor account when the TPP specified it in the consent, and each Confirmation of Payee NameMatchIndicator (ConfirmationOfPayee.Yes / ConfirmationOfPayee.Partial / ConfirmationOfPayee.No) surfaced to the customer. Each scenario is its own pre-production consent.
Authorise a payment consent whose DebtorAccount was supplied by the TPP. Screenshot your authorisation page showing that debtor account already resolved for the customer — not selected by them on the page.
ConfirmationOfPayee.YesAuthorise a payment whose Creditor name matches the account holder exactly. Screenshot your authorisation page showing the ConfirmationOfPayee.Yes indicator surfaced to the customer.
ConfirmationOfPayee.PartialAuthorise a payment whose Creditor name is close but not exact. Screenshot your authorisation page showing the ConfirmationOfPayee.Partial indicator surfaced to the customer.
ConfirmationOfPayee.NoAuthorise a payment whose Creditor name does not match the account holder. Screenshot your authorisation page showing the ConfirmationOfPayee.No indicator surfaced to the customer.
Review & generate
Review the summary below, add any comments, then download your submission. The ZIP contains a summary.html, your Testing Tool report, and every screenshot — attach it to your LFI Functional Certification Evidence Service Desk ticket.
- Organisation
- —
- Submitted by
- —
- Version
- V2.1
- Payment type
- SingleInstantPayment
- Segments
- —
- Rails
- —
- Payment limit
- —