Aani Integration Platform Software for Operators across the UAE

Who this is for: CBUAE-licensed institutions that hold an Aani connection - challenger banks, tier-2 banks, PSPs (Retail Payment Services licensees), SVF providers, exchange houses, and their sponsoring settlement banks. BY BANKS is a software consultancy and does not hold an AEP participant connection. We build the custom orchestration, customer journey, fraud, and reconciliation layers that the licensed institution operates on top of its own direct or indirect Aani connection.

Six connected capability areas: (1) Direct and indirect participation model with distinct settlement and liquidity handling. (2) ISO 20022-native message flow including pain, pacs, and camt family handling. (3) Request-to-pay customer journeys across biller, merchant, B2B, and split-pay. (4) Merchant QR and P2P flows designed around the 3-second benchmark. (5) Article 149 fraud intervention at real-time rail speed. (6) Reconciliation and exception workflow against AEP settlement.

Around those six, most operators also want: forthcoming cross-border corridor integration (India corridor in active development), e-direct-debit and e-cheque flow alignment, and integration with Sanadak dispute pathway.

Generic payment processor integrations handle Aani as another scheme alongside Visa, Mastercard, and UnionPay. The mechanics diverge - Aani is account-to-account, not card-based; ISO 20022-native, not ISO 8583; operates on a national switch, not a scheme network; and supports request-to-pay flows that cards don't model.

Custom Aani integration software is designed Aani-first with generic payment processing layered alongside rather than Aani adapted from a card-processor template. Direct and indirect participation mechanics are modelled natively. ISO 20022 is the primary format. Request-to-pay is first-class rather than bolted on.

AEP operates a two-tier participation model. Direct participants - primarily banks - settle directly with AEP. Indirect participants - payment service providers, stored value facility providers, exchange houses, and other non-bank licensees - settle via a sponsoring settlement bank that acts as their direct participant on AEP.

The platform models direct and indirect participation distinctly. Direct participants run full settlement mechanics with AEP liquidity management. Indirect participants route through their sponsoring bank with the sponsoring bank's settlement obligations preserved. Regulatory reporting, reconciliation, and exception handling respect the participation type.

Aani uses ISO 20022 XML messaging - pain.001 for payment initiation, pacs.008 for credit transfer, pacs.002 for status, camt.053 for statement, and camt.054 for debit/credit notification. The platform handles these messages natively with end-to-end tracking identifiers preserved for reconciliation.

Translation to and from ISO 8583 for card-scheme flows and to bank-specific proprietary formats sits as a bridge rather than a core constraint. Message enrichment, error handling, and dispute metadata preservation align with AEP specifications. When AEP extends message schemas for new features, changes are absorbed as configuration.

Request-to-pay shifts payment initiation from payer to payee. A biller, merchant, or B2B payee generates a request with amount, reference, and validity window. The request is delivered to the payer through their preferred channel - bank app, SMS, email - with consent-driven authorisation to complete the transfer.

Use cases span biller payments (utility, telecom, school fees), merchant e-commerce, B2B invoicing, and consumer split-pay patterns. The platform provides the customer UX wrapping around the AEP request-to-pay messaging, tuned to the 3-second transaction benchmark with Sanadak dispute pathway integrated.

Article 149 of Decree-Law 6/2025 obliges proactive customer notification of fraud incidents. Real-time Aani transfers need real-time intervention - transfers in flight for only seconds leave little window for reactive fraud handling.

The platform runs real-time screening - amount thresholds, velocity anomalies, counterparty history, device and behavioural signals - with customer-facing friction applied for high-risk transfers. Authorised push payment fraud patterns surface intervention before transfer completion. Breach notification automation handles Article 149 obligations. Fraud-data aggregation feeds CBUAE reporting continuously.

Here's where custom Aani integration platform typically sits in a wider stack.

Core banking and payment processing - we sit alongside Infosys Finacle, Oracle FLEXCUBE, Mambu for core ledger, and ACI Worldwide, FIS, Fiserv, FSS Technologies for payment processing and switching.

AEP connection infrastructure - we integrate with Al Etihad Payments for Aani and Jaywan rails, and with sponsoring settlement bank infrastructure for indirect participants.

Fraud and dispute - we exchange with NICE Actimize, Quantexa, Bottomline, and ComplyAdvantage for fraud signals, and with Sanadak dispute referral pathways for unresolved cases.

Integration approach is scoped during discovery. We don't ask you to rip and replace anything that works.

Discovery runs four to six weeks. Working with your payments, product, risk, compliance, and engineering teams, we map current AEP connection status, ISO 20022 handling, request-to-pay approach, fraud intervention practice, and reconciliation workflow. Output is a detailed report covering current-state map, platform architecture, integration scope, phased implementation plan, and fixed-price build proposal.

Build for a core Aani integration layer runs twelve to sixteen weeks from discovery completion. Full direct participation, request-to-pay rollout, and e-direct-debit alignment phases in over nine to eighteen months depending on product scope.

Pricing varies by transaction volume, product scope, and participation model. A bracket isn't published; discovery produces a fixed-price proposal with no obligation to proceed.