- One integration path to participating institutions instead of per-bank connectors
- Consent captured, displayed and revocable in the product, with an audit trail
- Security aligned to a recognised financial-grade API profile
- A data model that keeps only what each feature needs
Anonymised composite. Client names, identifying details and confidential figures are withheld; public facts are cited in the references.
The situation
A fintech serving customers in the UAE offered budgeting and cash-flow insights built on account data. Getting that data had meant a patchwork: screen scraping for some banks, bilateral integrations with others, and manual statement uploads as a fallback. Each connection broke differently, security reviews were difficult to pass, and the approach had no future as regulation matured.
The Central Bank of the UAE's Open Finance Regulation changed the picture by establishing a regulated framework for open finance services1. The question for leadership was how to move onto it cleanly, while continuing to ship features.
What had to be true
- One integration path through the regulated framework, replacing scraping and bespoke connectors.
- Consent as a product feature: customers see what they shared, with whom, for how long, and can revoke it.
- Financial-grade security that a bank's or regulator's reviewer would recognise.
- Data minimisation: store only what each feature needs, for as long as it needs it.
- Clear regulatory boundaries, including where free zone permissions do and do not apply.
The framework is described as having three parts: a trust framework, an API hub and common infrastructure services2. Commentary highlights that the API hub is operated by a Central Bank subsidiary, Nebras, as a single gateway between providers and licensed institutions, that participation is mandatory for licensees in respect of in-scope products, and that DFSA or FSRA permissions in the financial free zones do not by themselves grant access to the onshore hub3.
Architecture
The data flow, end to end
- ChooseCustomer picks a feature and sees exactly what data it needs and why
- ConsentConsent created with purpose, scope and expiry; customer authenticates with their institution
- TokenAccess tokens stored in the vault, bound to the client and never exposed to product services
- FetchHub connector retrieves only consented data through the API hub
- MinimiseOnly fields the feature needs are stored; the rest is discarded
- ExpireOn revocation or expiry, access stops and stored data is deleted
The hard part: security that reviewers recognise
Financial APIs attract determined attackers, and generic OAuth setups leave room for token theft and replay. The OpenID Foundation's FAPI 2.0 security profile defines a hardened profile of OAuth 2.0 and OpenID Connect for exactly these APIs; its security profile and attacker model were approved as final specifications, and conformance tests and certification are available45. Building to a recognised profile meant security discussions with partners started from a shared baseline rather than a custom design.
- Sender-constrained tokens and strong client authentication, so a stolen token alone is not enough.
- Keys held in a key management service or hardware security module, never in application configuration.
- Conformance testing in CI against the profile, run before every release of the connector.
- Product services given no direct access to tokens or the hub; they consume events and minimised data.
In open finance, consent is not a checkbox. It is the primary key of the whole data model: every token, fetch and stored field should trace back to one.
How it ran
- Map features to data needs
- Design consent journeys
- Retire scraping flows
- Consent service and vault
- Hub connector to profile
- Retention and audit
- Licensing and scope
- Policies and records
- Regulator engagement
- Regulatory scope
- Data needs per feature
- Target architecture
- Consent service
- Token vault and keys
- Audit and observability
- Hub connector
- Conformance testing
- Pilot feature
- Move features over
- Retire scraping
- Delete legacy data
Key decisions and trade-offs
| Decision | Alternative | Why |
|---|---|---|
| Integrate through the regulated hub | Keep bilateral and scraped connections | One standard path, a regulated basis and fewer breakages |
| Consent service as a core domain | Consent flags on user records | Purpose, scope, expiry and revocation need their own model |
| Build to FAPI 2.0 | Generic OAuth setup | Recognised baseline for financial APIs, with conformance tests |
| Minimise at ingestion | Store everything, filter later | Less risk, simpler retention and easier privacy answers |
| Tokens isolated from product services | Services call the hub directly | Smaller attack surface and one place to audit |
What I'd do again, and differently
Again: treat consent as the centre of the data model and build to a recognised security profile from the start. Differently: settle the licensing and regulatory perimeter before detailed design, especially the onshore and free zone question. It shaped which institutions and products were reachable more than any technical choice. Related reading: UAE PDPL and AI architecture and idempotent payment pipelines.
If you're building fintech products in the UAE, the fractional CTO in the UAE page explains how I work, or analyse your challenge and bring the result to a call.
- 1CBUAE issues Open Finance Regulation to ensure soundness, efficiency of open finance servicesWAM (Emirates News Agency) · 2024
- 2UAE Open Finance Regulation (briefing)Clifford Chance · May 2024
- 3UAE open finance (guide)Pinsent Masons Out-Law
- 4
- 5FAPI Working GroupOpenID Foundation