Open banking on the core APIs you already run
OBConnect connects to the API layer your own channels use - an ESB, an API gateway, a service tier in front of T24, Finacle, Flexcube or anything else - through a declarative mapping connector. It does the compliance shaping; your APIs only have to answer.
Banks don’t expose the core. Neither do we.
No bank lets anything integrate with core banking directly. Over the last decade every bank built an API layer on top of it, and its own mobile and web channels are the proof those APIs work. That layer is the integration target for open banking, and OBConnect is simply a client of it.
The platform owns everything the standard demands of the data: consent enforcement, basic-versus-detail minimisation, direction filtering, the wire format, pagination and the error contract. Your connector only has to fetch faithfully from APIs the bank already trusts.
For most banks that connector is configuration: a per-bank YAML file that declares endpoints, the authentication scheme, paging and the field mappings from your response shapes to the platform’s canonical model. Integration becomes writing mappings rather than writing Java.
Three ways to connect, one set of guarantees
Mapping connector
One signed engine and a per-bank YAML mapping - endpoints, OAuth2 or API-key auth, paging, formats and field mappings - validated in full when it is activated.
SDK connector
A stable, versioned Java SPI for handshakes and pagination the mapping language cannot express: two pure jars, no framework, and a conformance kit that proves the connector before it meets the platform.
Core adapters
For estates with a thin API layer, a per-core adapter for T24, Finacle or Flexcube built on the same SDK, by us or by your integrator, loaded as a signed bundle like any other.
The core is protected
Every call is bounded by timeouts, bulkheads and circuit breakers in the connector hub, so third-party load can never take down core banking.
Signed bundles
Connectors ship as signed bundles verified fail-closed at startup; partner code never runs in the same process as consent enforcement or TPP traffic.
Canonical model
Standard Packs map the wire format to a canonical model of accounts, balances, transactions and parties; connectors map that model to your systems. Neither side knows the other.
The connector hub inside OBConnect
Integration is one module of OBConnect. The same platform runs the FAPI edge, consent, the standard’s APIs, reporting and the operator console - so the data your connector fetches is minimised, audited and served in the regulator’s format before it leaves.
Explore the OBConnect platform →More OBConnect solutions
Open Banking Compliance
Meet the SAMA Open Banking Framework in weeks. OBConnect runs FAPI, consent, the standard's APIs and reporting on premises, on the core APIs your bank runs.
Read more →Consent Management
Issue, authorise, track and revoke open banking consents with an Arabic-first customer journey, a consent dashboard and a tamper-evident audit trail.
Read more →Frequently asked questions
Does OBConnect integrate with Temenos T24, Finacle or Flexcube?
OBConnect integrates with the API layer your bank runs in front of its core - an ESB, an API gateway or a service tier - whatever the core behind it. For most banks the mapping connector expresses that integration as a YAML mapping; where an estate exposes only a thin layer, a per-core adapter is built on the same SDK and loaded the same way.
What does our integration team actually have to write?
A mapping file: the base URL, the auth scheme, one endpoint template per operation and the field mappings from your JSON shapes to the canonical model. The engine, the resilience, the consent enforcement and the wire format are the platform’s. If a handshake or pagination scheme cannot be expressed as configuration, the SDK is the escape hatch and the conformance kit tells you the connector behaves before the platform ever sees it.
Can third-party traffic overload our core banking system?
No. The connector hub is the platform’s single client of your bank. Every call carries a timeout, runs inside a bulkhead that bounds concurrency, and sits behind a circuit breaker that turns a failing core into fast, well-formed errors instead of a pile-up. Bank-side failures are attributed separately from platform failures in the regulatory reporting.
What about customer authentication and payments?
Customer authentication is a first-class connector type because it is the most bank-specific part of every deployment; today the platform’s own FAPI authorization server handles it, with delegation into the bank’s identity provider on the roadmap. Payment initiation reaches your payment systems through the same hub, on the same resilience rules, as the pack for it lands.
Where does customer financial data live?
It flows through per request and is not stored at rest by default. The only caching is short-lived response caching in the connector layer where the standard’s freshness rules allow it, and everything happens inside your own data centre.
See your API estate connected.
Bring one API your channels use today - we will map it live.