API integration for Open banking
We build your Open banking connector
We go through a PSD2 aggregator to open your users' bank accounts to your application: balances, transactions, IBAN, with a consent that renews instead of lapsing.
- Senior product team
- banking integrations in production
- from scoping to monitoring
What is open banking and what does a banking data integration provide?
Open banking lets your application access your users' bank account data, with their consent, through APIs standardised by the European PSD2 regulation. In practice, you go through an account aggregator: such as Bridge or Powens, which covers several hundred French and European banks with a single integration. The practical result: your clients no longer send PDF statements, their transactions arrive structured and categorised in your tool. This is the foundation of many financial services: credit scoring, cash flow management, automated accounting.
What our clients build on bank aggregation
Multi-bank cash management
Consolidated balances, categorised flows and a forecast, for a client banking in three different places. One integration instead of three proprietary connectors.
Verification at sign-up
Account holder, IBAN and recurring income read at the source. No statement to request, to read through, and possibly to forge.
Dunning that stops on its own
A payment detected on the bank side ends the reminder sequence and updates the schedule. You no longer chase a customer who has already paid.
Payment initiated by bank transfer
A transfer payment link for high-value B2B invoices, where the card fee becomes hard to justify.
What it changes in your product
Engineering in service of a measurable outcome: reliable banking data, decisions in minutes, connections that hold.
A decision in minutes, not days
The first days of history are available as soon as the connection journey ends. Reviewing a file no longer waits on documents being sent.
Evidence that cannot be forged
The data comes from the bank, not from a file received by email. The check runs on real flows and over the period you defined.
Connections that do not drain away
Consent expires on a fixed date. We renew it before the deadline rather than discovering the cutoff when the user comes back.
An aggregator you can change
The provider sits behind an internal interface. Switching aggregator over coverage or pricing does not mean rewriting your product.
How we ship your banking connector
Scoping
Which aggregator, based on real coverage of your users' banks, which data, how long it is kept. We settle it before writing a line of code.
Development
Hosted connection journey, strictly incremental fetching, short-lived tokens renewed, signature verification on webhooks.
Statuses and journeys
Every connection status gets its message and its action: credentials to fix, something to do in online banking, a code to enter, a migration under way.
Monitoring
A reminder before consent expires, alerts on failing connections, a health dashboard. You know a flow is broken before your users do.
What an aggregation API allows
- Bank connections
- Creating the user, running the hosted connection journey, then tracking the state of each connection and the date its consent expires.
- Accounts, balances and IBAN
- Accounts attached to a connection, with balance, IBAN and holder identity data. The basis for a verification or a cash dashboard.
- Categorised transactions
- History per account, categorised by the aggregator, with incremental fetching based on the last modification date.
- Payment initiation
- With the aggregators that offer it, transfer payment links and payment requests, with their statuses and their webhook events.
The vocabulary of open banking
- AISP and PISP
- The two regulatory statuses for account access: reading accounts on one side, initiating payments on the other. In nearly every project the aggregator holds them, neither you nor us.
- Item
- A connection between a user and a bank, distinct from the account itself. It carries a status that changes over time and that belongs in your interface.
- authentication_expires_at
- The date the customer's strong authentication expires for that connection. The field exists precisely to be watched and anticipated, not discovered after the fact.
- Connect session
- The connection journey hosted by the aggregator, where the user authenticates with their bank. The same journey handles renewal, with forced re-authentication.
- Incremental fetching
- You store the last modification date of the transactions already read and pass it back as a parameter. That is what keeps you inside the quotas instead of re-reading everything.
- PSD2 consent and GDPR consent
- Two distinct notions handled separately: one authorises access to accounts, the other governs the processing of personal data. Banking data falls under both.
The real constraints of bank aggregation
Consent expires after 180 days
Strong authentication stays valid for 180 days after the initial connection, which is regulatory and cannot be worked around. Without a reminder before the deadline, your connection base empties itself within six months.
A connection status is not an error
Credentials to update, something to do in online banking, a one-time code expected, a bank migration under way: each case calls for a different message and action. A single message makes the product fail.
History depth depends on the bank
It runs from zero to thirty-six months depending on the institution, a connection can be partial with accounts temporarily unavailable, and the refresh stays periodic. This is not real time.
A webhook that does not land can be lost
Retries are spread over one to two days, and some providers give up after a handful of consecutive failures. You need a durable queue and a scheduled catch-up sweep.
PSD2 aggregation or a direct banking API?
Two ways to read accounts from your application. The right one depends on who holds the accounts, not on the technology.
| Criterion | PSD2 aggregationBridge, Powens, Tink | Direct banking APIQonto, Revolut Business |
|---|---|---|
| Banks covered | Most French banks | The one institution concerned |
| Setup on the user side | Connection journey and consent | API key or authorisation declared once |
| Depth of data | Description, amount, date, categorisation | Labels, native categories, attached receipts |
| Freshness | Periodic refresh | Webhooks as events happen |
| How long access lasts | Consent to renew every 180 days | Token refreshed server-side |
| Regulatory status | Held by the aggregator | Not applicable, these are your own accounts |
| The right case | Your users bank in different places | Every account sits in the same institution |
The two often combine: your own bank's API for your accounts, aggregation for your customers'. It is a scoping trade-off, not a permanent choice.
What we measure on a banking integration
The other banking APIs
If every account involved sits in the same institution, direct access is worth discussing during scoping.
QontoDirect, rich access to your own accounts, outbound transfers included.
Revolut BusinessMulti-currency accounts and international payments, in direct access.We combine open banking with
The stack that surrounds bank aggregation on our projects.
Open banking integration: your questions
Through an aggregator, not through each bank. The journey is always the same: you create the user at the aggregator, mapped to your own identifier, you open a hosted connection journey where they authenticate with their bank, then you read the accounts and transactions attached to that connection. Fetching afterwards is strictly incremental, triggered by refresh webhooks, storing the last modification date already handled. Re-reading the whole history on every pass saturates the quotas within minutes.
In the vast majority of projects, no: the aggregator holds the regulatory status for account access, neither your company nor your development partner. That is one of the reasons to use an aggregator rather than contract with each bank. What remains yours is the handling of personal data: minimisation, hosting in the European Union, a defined retention period, effective purging, and a deletion path that also cuts the connection at the aggregator. Banking consent and GDPR consent are two separate matters.
Their promise is close, their implementation details are not. The data models differ, so do the webhook authentication mechanisms, and the policy on giving up when an endpoint is unavailable varies sharply from one provider to another: with some, a handful of consecutive failures is enough to lose events for good. The choice comes down to three concrete criteria, in this order: real coverage of your users' banks, the functional scope you need, then pricing. We isolate the provider behind an internal interface so that the choice stays reversible.
A first useful flow, typically reading accounts and transactions after a connection journey, ships in three to four weeks. A full chain takes more like six to eight weeks, and the extra time does not go into API calls: it goes into the connection status table, consent renewal, retry logic and data purging. That is exactly what separates a prototype that works in a demo from a product that still holds six months after launch.
Because the customer's strong authentication expires 180 days after the initial connection. It is a European rule, not a flaw in the aggregator, and no implementation can work around it. The only answer is renewing early: a daily job reads the expiry date of every connection, warns the user several days before the deadline and offers a one-click reconnection. That is the difference between a connection base that sustains itself and one that empties out within six months. The other frequent causes are a credentials change and an action to complete in online banking.
A bank aggregation project?
Let's talk. 30 minutes to scope your need, check the real coverage of your users' banks and tell you honestly what is feasible.
Discuss my banking project