Open banking compliant in weeks, not months.
OBConnect is the open banking compliance platform for banks and fintechs in Saudi Arabia and the GCC. It runs the whole lifecycle - TPP trust, FAPI authorization, consent, the standard’s APIs, audit and reporting - and plugs into the APIs your bank already has.
Compliance is seven projects at once. OBConnect is one deployment.
Every bank pulled into open banking by its regulator discovers the same thing: “being compliant” is not one project. OBConnect is the open banking compliance platform that ships all seven, pre-integrated, and keeps them current as the standard evolves.
Standards-compliant APIs
With the availability and response-time SLAs the framework mandates.
FAPI-grade authorization
A hardened OAuth and OIDC server wired to your customer authentication.
Consent management
Lifecycle, customer dashboards, and the regulator-shaped journey screens.
TPP identity and trust
Directory, licence, role and certificate checks on every request.
Core integration
Without destabilising the systems that run the bank.
Reporting and audit
Reports in the regulator’s format and an audit trail that survives supervision.
Developer portal and sandbox
So licensed third parties can actually build against you.
Deployed in your data centre, configured per bank, current with every release of the standard.
Every stage of open banking, managed.
From the moment a third party is admitted to the moment a customer withdraws access, OBConnect runs the regulated path end to end. Your systems only ever answer one question: what does this customer hold?
- 01
- 02
- 03
- 04
- 05
- 06
The regulator-shaped consent journey, in your brand.
The screens ship with the platform: Arabic-first, right-to-left, WCAG 2.2 AA, white-labelled per bank. Permission wording and the step sequence come from the Standard Pack, so a customer-experience guideline update is a pack update, not a rebuild.
Who is asking, and for what
The requesting party, its registered identifier, the purpose, the data clusters and how long access lasts - before the customer continues.
The same journey, right to left
Both languages are co-primary. Layout, copy and the pack-authored permission wording all render natively in Arabic.
Choose the accounts
Only what the customer selects is shared. Account numbers are masked; the journey never shows a full IBAN.
Confirm and share
One last look at permissions, accounts and duration. Approve or deny - both are recorded and both resume the TPP’s flow.
The consent dashboard
Every connection the customer has allowed, its status, what it can see and when data was last taken - with a way to stop sharing.
Everything the SAMA framework asks for, in one open banking platform.
Nine modules on a shared foundation, each with one reason to change: a security profile update touches the edge, a standard release touches pack content, a new core touches only a connector.
Open banking gateway
Mutual TLS, FAPI header enforcement, routing by standard version and per-TPP throttling, all at the edge - before a request reaches anything that matters.
FAPI authorization server
FAPI 1.0 Advanced: pushed authorization requests, signed request objects, private_key_jwt, PKCE and certificate-bound tokens. Revoke the consent and every derived token dies with it.
Consent manager
The consent system of record: the standard’s statuses and immutable flags, every transition evented and audited on the same transaction, customer binding enforced where the record lives.
Consent journey and dashboard
The regulator-shaped screens: Arabic-first, right-to-left, WCAG 2.2 AA, white-labelled. Customers review, select accounts, approve, and later see and revoke everything they granted.
Participant directory
Synchronised with the national trust framework: licence, certification and role enforced on every request, certificate chains validated at the edge. An AISP token can never reach a payments endpoint.
The standard’s APIs
Account information served from the Standard Pack: the published OpenAPI is the enforced one, byte for byte. Payment initiation and confirmation of funds follow on the same mechanism.
Compliance and reporting
The regulator’s report set generated from the event backbone, availability and response time measured at the edge where the standard defines them, and a hash-chained audit trail exportable to WORM storage.
Developer portal and sandbox
Branded documentation served from the same signed pack the gateway enforces, an onboarding runbook, error glossary, published rate limits and a sandbox behind the same edge as production.
Operator console
Bank staff run the platform through their own SSO, four roles and maker-checker on every privileged change: admit or suspend a TPP, activate a pack, revoke a consent, verify the chain.
Core banking integration on the APIs you already run.
Banks don’t expose the core. They expose the API layer their own channels use - an ESB, an API gateway, a service tier. OBConnect is a client of that layer. It does all the compliance shaping; your APIs only have to answer faithfully.
# your-bank-mapping.yaml · configuration, not codebank: { id: your-bank, displayName: "Your Bank" }baseUrl: "https://api.internal.yourbank.sa"auth:scheme: oauth2-client-credentialstokenPath: /oauth2/tokenclientIdRef: oauth-client-id # secrets by referenceclientSecretRef: oauth-client-secretoperations:listAccounts:path: "/customers/{customer}/arrangements"items: /bodymapping: accountmappings:account:accountId: /arrangementIdcurrency: /currencystatus: { path: /status, map: { ACTIVE: Enabled, DORMANT: Dormant } }identifications:- scheme: { const: KSAOB.IBAN }identification: /iban
Secrets are referenced, never written: the deployment supplies them. Unknown keys, misspelt canonical tokens and dangling references refuse to load, with the breadcrumb of the mistake.
Mapping connector
Most banksOne signed engine, a per-bank YAML file. Endpoints, auth scheme, paging and field mappings from your response shapes to the canonical model. Integration is writing mappings, not Java.
SDK connector
Escape hatchA stable, versioned Java SPI for handshakes and pagination the mapping language can’t express. Two pure jars, no framework, and a conformance kit that proves the connector before it meets the platform.
Core adapters
On requestFor estates with a thin API layer: a per-core adapter built on the same SDK, by us or by your integrator, loaded as a signed bundle like any other.
TPP load can never take down core banking: every call is bounded, bulkheaded and circuit-broken in the hub.
Your core stays untouched: nothing is installed in it, and no customer financial data is stored at rest by default.
Connector bundles are signed and verified fail-closed at startup; partner code never runs in the regulated data path.
Bank-side failures are attributed separately from platform failures, because the distinction matters during supervision.
Current with every release of the SAMA standard.
Each release of a national standard ships as a signed, versioned Standard Pack: content the platform loads, not code the bank forks. Two versions run side by side through the regulator’s migration window, and activating a new one is a maker-checker decision with no downtime.
- Side-by-side versions, each on its own base path, for the overlap window the regulator mandates
- Zero-downtime activation, approved by a checker and sealed on the audit chain
- Bilateral (KSA, Bahrain) and hub-mediated (UAE) market models on one bank-side foundation
- The published API document is the enforced one: the portal serves the pack byte for byte
- OpenAPI and payload validators
- Permission and consent model
- Security profile for edge and auth server
- Journey copy, Arabic and English
- Report templates and SLA thresholds
- Sandbox scenarios and conformance tests
Evidence your regulator will recognise.
- Hash-chained, tamper-evident audit trail, exportable to WORM storage
- The regulator’s report set generated from the event backbone
- Availability and response time measured at the edge, where the standard defines them
- Correlation id on every response, including denials, for problem resolution
Open banking for banks and fintechs in Saudi Arabia and the GCC.
Meet the framework without a multi-year programme.
- Deployed in your data centre and operated by your staff - air-gap ready, no runtime egress
- Connects to the API layer your channels already use; the core stays untouched
- Built to pass architecture and infosec review: maker-checker, SSO, keys in your HSM
- Arabic-first customer experience aligned to the SAMA CX guidelines, white-labelled
- Certification evidence as a product: audit chain, report set, conformance runs
Compliance without building a compliance team.
- The compact profile runs the whole platform on a single node for a PoC or a small estate
- The same FAPI edge, consent engine and journey a tier-1 bank runs, from day one
- Developer portal and sandbox out of the box, so partners integrate while you certify
- Grows into the full high-availability profile as you do, without a migration
- Drops into Wahid, our back office, or stands alone beside what you already run
On-premise, air-gap ready
Licensed software in your data centre. No SaaS, no runtime egress; directory sync and pack updates enter through a controlled, signature-verified channel.
FAPI 1.0 Advanced
Mutual TLS everywhere a TPP touches, PAR, signed request objects, private_key_jwt, PKCE and certificate-bound tokens re-checked at the edge.
Keys in your custody
Signing and transport keys generated and held in the bank’s HSM through PKCS#11. Nothing about the platform needs the vendor in the room.
Maker-checker on every change
No privileged operation runs on one person’s say-so, and no script with a secret can approve one. Every decision is on the audit chain.
Weeks, not months. Without losing control.
Standards as content. Integration as configuration. Evidence as a product.
A typical engagement runs in weeks because the platform is the product a bespoke build should have produced: nothing regulator-facing is written for you, and the only bank-specific work is the mapping to your own APIs.
- 1Week 1
Deploy and discover
The compact profile running in your environment, and a gap analysis of your API estate against the standard’s surface: coverage, headless authentication, display versus wire data.
- 2Weeks 2 to 3
Connect
The mapping connector written as configuration against your APIs, with the conformance kit green before the platform ever sees it.
- 3Weeks 4 to 6
Brand and operate
The journey white-labelled, your staff on the operator console with their own SSO, the developer portal and sandbox opened to licensed third parties.
- 4Then
Certify and go live
Conformance runs, the evidence bundle, the regulator’s report set, and a platform your own team operates without the vendor in the room.
Explore OBConnect by need.
Three shorter reads, one per question banks ask first, and the briefing decks to share with your team.
Frequently asked questions
What is OBConnect?
OBConnect is an open banking compliance platform that a bank or fintech deploys on premises. It provides the TPP-facing gateway, a FAPI-grade authorization server, consent management with the regulator-shaped customer journey, participant directory integration, the standard’s APIs, regulatory reporting, a tamper-evident audit trail, a developer portal with sandbox, and an operator console - pre-integrated, so compliance is a deployment rather than a multi-year programme.
Which open banking standards does OBConnect support?
OBConnect ships with a Standard Pack for the SAMA Open Banking Framework in Saudi Arabia, with account information services live and payment initiation and confirmation of funds following on the same mechanism. Standards are versioned content, so new releases run side by side with the old one, and Bahrain and UAE packs are planned on the same foundation, covering both the bilateral and the hub-mediated market models.
How does OBConnect integrate with our core banking system?
OBConnect never touches the core directly. It connects to the API layer your own channels already use - an ESB, an API gateway or a service tier - through a connector hub that holds your credentials once and bounds every call with timeouts, bulkheads and circuit breakers. Most banks integrate with the mapping connector: a per-bank YAML file that maps your API responses to the platform’s canonical model, with no Java to write. A versioned SDK covers anything the mapping language cannot express.
Is OBConnect cloud or on-premise?
On-premise. OBConnect is licensed software that runs inside your own data centre on Kubernetes, with a compact single-node profile for proofs of concept and small estates. Nothing needs internet access at runtime; directory synchronisation and pack updates enter through a controlled, signature-verified channel. Customer data never leaves your perimeter.
How long does it take to become compliant with OBConnect?
Weeks rather than months. Nothing regulator-facing is built for you: the only bank-specific work is mapping the platform to your APIs, branding the customer journey and onboarding your staff. A typical engagement runs deploy-and-discover in the first week, connector and conformance in the following two, and branding, portal and operations after that, before conformance testing and go-live.
Does OBConnect work with Wahid?
Yes. OBConnect drops into Wahid, our back-office platform, so consent operations and TPP management sit beside the rest of your bank’s operations, or it stands alone beside the systems you already run.
See OBConnect in action.
A guided walkthrough of the lifecycle, with your API estate in mind.