Open Banking · Open Data · authorized API integration
Open Banking made account data portable — but only for the institutions a scheme reaches. For one named consumer or business app at a time, we work out which rail it is on: a regulated Open Banking / Open Data consent flow, or, where no scheme covers it, authorized protocol analysis of the app's own interface. Either way you get the same thing back — runnable source, an OpenAPI and auth-flow spec, automated tests and interface documentation.
Every engagement starts with one decision: which rail this app is actually on — and we tell you plainly which we would use, and why.
UK Open Banking, EU PSD2 Account Information Services, Open Finance Brasil, Australia's Consumer Data Right and India's Account Aggregator each give a consented, standardized read of accounts, balances and transactions through a FAPI-secured OAuth2 flow.
When the app you name is covered, we build against that scheme — its consent screen, its permission scopes, its token and re-authentication lifecycle. It is the most durable route and the one regulators intend, so it is the one we recommend whenever it is available.
Most consumer and business apps — wallets, lenders, credit, niche banks, investing, payroll — sit outside every scheme, or expose only a fraction of what the user sees inside them.
Open Data is the principle: the account holder's data is theirs, portable and interoperable. The regulated rail simply hasn't reached that app. There we reach the same data through authorized, documented protocol analysis of the app's own interface, or a user-consented session — and deliver an identical clean, documented API over it.
The honest version: a regulated scheme is better when it exists, and we will say so. But coverage is the exception, not the rule — which is why most of the work below is the second path, done to the same standard as the first.
One discipline — reaching an app's data through an authorized channel and shipping the code that does it.
Where a regulated scheme exists, we build against its consent and FAPI/OAuth flow — accounts, balances, transactions, standing orders, beneficiaries, statements and product data — not around it.
The interoperability principle behind Open Banking, applied past finance: a user's data made portable into your stack under their consent, normalized to one schema.
For apps no scheme covers, we map the client–server traffic, auth flow and token lifecycle so the data the user sees becomes a documented, callable interface.
Scoped permissions, Strong Customer Authentication, token refresh and the re-auth window built into the integration so a sync survives instead of silently expiring.
A fragile scrape rebuilt into a maintained interface; scheduled, resumable extraction with retry, rate-limit and re-auth handling wired in.
Every engagement lands an OpenAPI/Swagger schema, an auth-flow report and runnable source in Python and Node.js — not a slide deck.
Which regime applies depends on the app and the account holder's jurisdiction. We implement to the one that fits — and to your or your partner's accreditation where the scheme requires it.
OBIE Open Banking Standard; CMA9; AISP/PISP roles under the FCA.
Account Information Services; Berlin Group NextGenPSD2 and STET; SCA and eIDAS.
OpenID Foundation Financial-grade API; mTLS or private_key_jwt, PKCE.
Banco Central do Brasil phased scheme; dynamic client registration.
Financial Data Exchange API; CFPB personal financial-data rights rule.
CDR open-banking regime; accredited data recipient model.
RBI consent-artefact model — FIU, FIP and consent-manager flow.
No scheme yet — the Open Data principle delivered by consented protocol analysis.
You supply two things. Access, credentials, sandboxes and any compliance paperwork are arranged with you as part of the work — never a wall you clear first.
One named consumer or business app — banking, wallet, credit, lending, payments, investing.
Which data domains matter — balances, transactions, statements, credit file — and how you want it delivered.
We pick the authorized route — scheme or protocol analysis — set up access with you, and write the integration.
Source, OpenAPI/auth-flow spec, automated tests and docs — in one to two weeks.
Whether the route is a regulated scheme or a consented session, the consent lifecycle is engineered in — not bolted on, and never the reader's problem to pre-clear.
Only the permissions the integration needs — the data clusters, not the whole profile.
Strong Customer Authentication carried through the consent flow exactly as the scheme requires.
Consent TTL and the re-auth window modelled so a long-running sync re-consents, not silently dies.
Revocation honoured immediately in the session lifecycle; access scoped and logged throughout.
Each brief maps one app's data, the authorized route in, and what ships. A sample — the full log is on the updates page.
Same deliverable whichever rail the app is on. Pick how you want to run it — both stated plainly, no upfront surprise.
Paid after delivery, once it works for you.
You get runnable API or protocol-implementation source plus the OpenAPI/auth-flow spec, tests and interface documentation. It runs on your own infrastructure. You only pay once the delivered code works against your case.
No upfront fee.
We host the integration and you call our endpoints, paying only for the calls you make. The right fit when you would rather not run or maintain the extraction yourself.
Either way the build cycle is one to two weeks, and access, a consenting test account and any NDA or compliance paperwork are handled with you during onboarding.
The questions integrators actually open the conversation with.
No. Where a regulated scheme covers the app — UK Open Banking, EU PSD2 Account Information Services, Open Finance Brasil, Australia's Consumer Data Right, India's Account Aggregator — we build against that scheme's consent and FAPI/OAuth flow. Most consumer and business apps are in no scheme at all; for those we reach the same account data through authorized, documented or user-consented protocol analysis of the app itself. The deliverable is the same either way.
One of four, decided per app: a regulated Open Banking or Open Data consent flow; an official or partner API; documented protocol analysis of the app's own client-server traffic; or a user-consented session the account holder grants. We pick the one that is durable for that app and set the access up with you during onboarding — it is not a precondition you must satisfy before we start.
The standard Account Information clusters — accounts and parties, balances, transactions, direct debits and standing orders, beneficiaries, statements, and product or rate data — plus whatever the specific app exposes beyond a scheme, such as a credit file, payouts, rewards or on-chain balances. We normalize them into one schema so a balance reads the same regardless of which rail it came from.
We build the consent lifecycle in, not around it: scoped permissions requested explicitly, Strong Customer Authentication carried through the flow as the scheme requires, consent expiry and the re-authentication window modelled so a long-running sync re-consents instead of silently dying, and revocation honoured immediately. For schemes with a ninety-day style reauthentication rule we design the refresh around it.
We are an engineering studio, not a regulated account-information provider. Where a regulated permission or an eIDAS QWAC/QSEAL certificate is required, the integration is implemented to your or your partner's accreditation; where no scheme applies, access is user-consented and authorized. We work only with authorized, documented or consented data flows, scoped and logged.
Compliance as professional posture, not an entry barrier.
We work with authorized, documented, or user-consented data flows and frame interface work as reverse engineering and data extraction for interoperability — the Open Data principle, applied to apps a regulated scheme has not reached. Access is scoped and logged, consent expiry and revocation are honoured in the session lifecycle, and we pull only the fields the integration needs. Where a regulated permission or eIDAS certificate is required, the build is implemented to your or your partner's accreditation — we do not represent ourselves as a licensed account-information provider. Compliance posture is shaped per jurisdiction and named on each app's brief, not bolted on, and we sign an NDA where a client needs one.
That is the whole brief from your side. We come back with the rail this app is on, the deliverable and the timeline — usually within a day.