Integration of a banking API
The account, not the PDF statement, feeds your tools
We connect your business accounts, or your users' accounts under PSD2, to the product: movements, balances, transfers. Distinct from card collection.
- Bank connectors in production
- AIS and PIS scoped
- consent tracked
What is a banking API and when should you have it integrated?
A banking API gives your application structured access to accounts, transactions and, depending on the provider, transfers. With a professional neobank such as Qonto, you talk to your own bank. In open banking, you go through a PSD2 aggregator to read your users' accounts, with their consent. You have the integration built when manual reconciliation no longer holds, when cash must be visible continuously, or when a transfer should leave from a business event rather than a click in the bank interface.
When the statement is still a PDF
The bank keeps the accounts. Until the movement reaches the product, matching, treasury and chasing stay manual.
We match statements by hand at month end
We attach every transaction to its invoice as soon as it arrives, with a reference carried end to end. Month-end matching disappears.
I only see my cash position two weeks late
Balances and movements feed your application continuously. You decide on today's figures, not on a stale export.
We chase customers who have already paid
Collection stops the reminder sequence. A payment received is no longer information lost in a PDF statement.
Open banking consent lapses without anyone seeing it
We track the expiry date and prompt the user before the cut. The connection is renewed instead of dying in silence.
What each banking API actually involves
Open banking
PSD2 aggregationYou do not talk to each bank: a PSD2 aggregator (Bridge, Powens, Tink) holds the licence and unifies accounts and transactions. The difficulty is not the first connection, it is consent that expires and must be renewed, otherwise the flow stops without a sound. We build that prompt into the product.
- One model for several banks
- Consent renewed, not abandoned
- Multi-institution cash view
Qonto
Business bankThe API of a French professional bank: reading accounts and transactions, supporting documents, creating transfers. Authentication by key for internal use, OAuth when you connect your own customers' accounts. The integration topic is reconciliation and business triggering, not access to the statement.
- Transactions and transfers in the product
- Signed webhooks on movements
- Receipts pushed into accounting
Revolut Business
Multi-currencyA business bank useful when your flows go through several currencies or several countries. No detailed technical sheet here: the integration is judged at scoping on the accounts to read, the payments to trigger and the reconciliation expected, not on an announced catalogue of endpoints.
- Business accounts in the product
- Flows to reconcile with invoicing
- Scope settled at scoping
Four systems we run on the account
Reconciliation by carried reference
The invoice leaves with a key. The movement brings it back. Free transfers and partial amounts become exceptions, they are not matched by eye.
Multi-institution treasury
Balances and categorisation in the application, including when accounts are split. You decide on the day, not on day 15.
Chase cut on incoming payment
The credit stops the sequence. Credit control stops chasing a client who already paid.
Transfer born from a business approval
A step in the tool creates the supplier payment. The IBAN is no longer copied into the bank UI.
CFO, credit, ops: what we carry with you
We do not “connect the bank”. We set reconciliation keys and the consent cycle with finance.
The CFO stops waiting on matching
Movements arrive as they happen. Close time goes back to control, not to retyping statements.
Credit sees the payment the same day
The chase stops. The customer relationship is no longer damaged by a mail sent too late, or too early.
Ops trigger the transfer without copying the IBAN
The business approves, the connector carries the failure status. Nobody believes they paid if the bank refused.
The DPO treats the account as sensitive data
Isolated tokens, access log, minimisation. We design the connector as a processing activity to document.
What we have shipped, and why it transfers here
The method a bank API forces
AIS / PIS scope
Read, transfer, or both. Native bank or PSD2 aggregator.
Deliverable: AIS / PIS scopeConsent cycle
Duration, renewal, reminder before expiry.
Deliverable: consent journeyReconciliation keys
End-to-end reference, exception queue, no match by eye.
Deliverable: reconciliation ruleSensitive data
Isolated tokens, log, paginated history, no dump.
Deliverable: processing recordWhat nobody tells you before you sign
Open banking consent has a lifetime
Without a prompt in the product, the connection expires and the dashboard empties. This is not an API detail, it is a user journey to design at scoping.
A transfer is not a simple POST
Validation, beneficiary, ceilings, failure status: the business trigger must know these states, or you believe you have paid while the bank refused.
History can be backfilled, but not overnight
Pagination windows and quotas force a spread backfill. An improvised bulk import gets cut off, and leaves a half-loaded directory.
Bank data is sensitive data
Isolated tokens, access log, minimisation: the connector is designed as a processing activity to document, not as one more export in a cron.
What we measure on a banking project
Banking API integration: your questions
Three steps. First choose the model: your own professional bank, or aggregation of your users' accounts through a PSD2 provider. Then build a connector on the server side, with secrets isolated, a retry queue and webhook verification. Finally handle the lifecycle: history pagination, consent renewal, transfer statuses. The sensitive part is never the first call that lists transactions, it is what happens when the connection expires or a payment is refused.
Qonto exposes your company's accounts: you are the holder, you read your movements and you can trigger transfers. Open banking exposes your users' accounts, with their consent, through an aggregator that holds the regulatory licence. The first case serves internal reconciliation and cash. The second serves a product that needs to see its customers' bank. The two combine, and it is not the same contract, nor the same authentication journey.
It depends on the perimeter far more than on the brand. Reading transactions from a single account and pushing them into accounting costs far less than multi-bank aggregation with consent renewal, or a chain of transfers triggered by the business. History backfill and failure handling often weigh more than the nominal flow. We scope the perimeter up front and give a firm estimate.
For aggregating your users' accounts, the licence is held by the aggregator (Bridge, Powens, Tink), not by your application. You remain responsible for the consent journey, token storage and the information given to the user. For a professional bank of which you are the holder, the topic is contractual with the institution, not a PSD2 licence to obtain yourself. That is clarified at scoping, with your IT lead and your counsel.
Yes, provided you carry a reference end to end rather than matching on amount and date. We set that reference when the invoice is issued, then we wait for it on the movement. Remaining cases (free-text transfer, partial amount, truncated label) go into an exception queue, they are not matched by guesswork. A silent, wrong reconciliation costs more than a visible exception.
Your accounts, or your users' accounts?
30 minutes to decide native bank versus PSD2 open banking, and what that imposes on consent and reconciliation.
Discuss my banking project