APIs & open banking
Account data and payment initiation, with consent that does not expire quietly.
Account aggregation, payment initiation, consent lifecycle and the API security work underneath. We build a provider-agnostic layer so your product asks one internal interface for balances and transactions. Licensed access under PSD2 belongs to the regulated party, either your own authorised entity or the aggregator you contract.
Where it fits
The problem
Consent lapses at the end of its window and the first sign is a dashboard of stale balances plus a support queue asking why. Each bank returns a different shape for the same transaction, so the parser grows special cases nobody owns. Reconnection is a dead-end screen that sends the customer back to the start.
What we build
We normalise provider payloads into one internal account and transaction model, track every consent with its scope and expiry as first-class data, and prompt for renewal before it lapses. Payment initiation gets idempotency keys and a status machine, because a redirect that returns nothing is the common failure.
How we engage
Senior engineers who read the bank API specs and the deviations rather than the marketing pages. The consent store and the aggregation workers run in your infrastructure, under your keys and your data retention rules. We hand over tests against provider sandboxes, the runbooks, and code yours to run.
What we build
Six pieces of open banking plumbing we build most often.
Account aggregation
We pull accounts, balances and transactions on a schedule, page through provider quirks, and normalise the result into one model with the original payload kept for audit. Categorisation sits above that. Before this, product teams compare a balance from one bank against a transaction list from another and cannot explain the gap.
Payment initiation
A payment initiated at a bank can return approved, rejected, or nothing at all when the customer closes the tab. We build the redirect and decoupled flows, poll status against a state machine, and hold unresolved payments in a queue a human can work. Support stops guessing if money moved.
Consent management
Each consent becomes a record with scope, granted time, expiry and provider reference, plus an event history you can show a customer or an auditor. Renewal prompts fire before the deadline and revocation propagates to the provider. The alternative is silent expiry discovered by a customer opening a broken screen.
API security
Bank interfaces expect mutual TLS, signed requests and certificates with a renewal date somebody must own. We set up the certificate handling, token refresh, key rotation and secret storage, then alarm on expiry ahead of time. Certificate lapses tend to take down every bank connection on the same quiet morning.
Provider orchestration
Coverage differs by country and bank, so we route each connection to the aggregator that supports it and fail over when one degrades. Health checks and per-provider error budgets sit in the same dashboard. Teams tied to a single vendor usually find out about a coverage gap from a customer complaint.
Your own API surface
When your product becomes the thing others integrate with, you need versioned endpoints, outbound webhooks, rate limits, keys per client and a sandbox that behaves like production. We build that surface and the reference documentation. Partners otherwise integrate against undocumented behaviour and every change turns into a breakage report.
Aggregated accounts with consent state on screen
The demo links two bank connections, shows normalised transactions, and puts each consent with its expiry and renewal prompt next to them.
How we work
Discover
Systems, constraints, and the regulation you operate under get mapped before implementation starts, so the design accounts for what already runs and for what examiners will ask about.
Architect
A design that fits your stack. Integration-first, self-hostable, and built to change as rules, regulation, and volume do.
Build
Senior engineers ship in tight increments, each tested and reviewed as it goes, so the system is reviewable at every step instead of only at the end.
Harden
Security, compliance, and load-testing run inside the build, so controls, audit trails, and peak-volume behavior are proven before launch.
Run
The handover includes clean, documented systems, with the option to keep the same engineers operating them once they are live.
Why Oxagile
One internal model per domain
Your product code should not know which aggregator answered. We keep provider adapters behind one account, transaction and consent model, so adding a market or swapping a vendor stays inside the adapter layer. The mapping tables are documented, and the raw payload is retained when someone disputes a figure.
Consent treated as product
Expiry, scope and revocation get screens, copy and reminders, because a lapsed consent is a churn event dressed as a bug. We instrument reconnection so you can see where people drop. Regulators expect a clear record of what the customer agreed to, and that record lives in your database.
Clear about the permissions
Account information and payment initiation are regulated activities under PSD2. The authorisation sits with your entity or with the aggregator whose licence you use, and we design to whichever applies. We are the engineering vendor. We build to the specification, the security profile and the audit obligations that come with it.
Questions
Do we need our own open banking licence, or can we use a provider's?
Both routes exist. Account information and payment initiation services need authorisation from a regulator, and many product teams operate under the licence of a contracted aggregator acting as the regulated party. Others become authorised themselves for control and cost reasons. We build the same layer either way, and your counsel confirms which route your business model requires.
How do we stop consents from expiring without anyone noticing?
Store each consent as a record with its expiry and treat that date as an event source. Reminders go out before the deadline, the connection status is visible in your own admin, and a lapsed consent triggers a reconnection flow rather than a blank screen. PSD2 strong customer authentication means the customer must re-authenticate, so the copy matters as much as the code.
Can we switch aggregators without breaking the product?
That is what the adapter boundary is for. Your code reads one internal model, and each aggregator has its own adapter and mapping table. The parts that hurt are consent portability, since consents are usually tied to the provider that obtained them, and historical transaction ids. We plan a dual-run period and a reconnection campaign into any migration.
What happens to the bank data we pull, and who is responsible for it?
You are the controller in most arrangements, and the retention rules are yours to set. We keep raw payloads separate from the normalised model, encrypt at rest with your keys, and build deletion that removes both when a customer revokes consent or asks to be forgotten. The scope of what you may store follows the consent the customer granted.
Part of Embedded Finance
The finance layer inside your product, built and run by the same engineers.
Financial features,
native to your product.
Tell us what you want to embed: payments, cards, lending, payouts. We'll build the integration, orchestration and ledger around your providers.