Open Banking: where integrations break at scale
Open Banking integration rarely breaks at the level of a single request — it breaks at scale. When there are two banks and a dozen clients, each is handled by its own connector: its own fields in the statement, its own error codes, its own date and amount format.
As soon as there are twenty banks, support turns into constant manual work, and connecting a new partner to bank accounts takes weeks instead of days.
The main cost of such a scheme is not development, but operations. Interfaces have different limits on the number of requests, different maintenance windows, and different requirements for confirming the account owner.
Under peak loads, the service receives rejections from bank interfaces, goes into retries, and either duplicates operations or loses part of the history.
At the same time, a failure of one bank looks like a failure of the entire service because there is no single view of the client's accounts.
PSD2 account access adds consents to this: they have a limited lifetime, can be revoked by the client at any time, and require timely token refresh.
If consent is stored as a user attribute rather than as a separate entity with a status and lifetime, reconciliations and reporting begin to diverge from reality.
Bank data aggregation is solved at the model level, not by the number of connectors: a unified account and transaction schema, idempotent keys, deduplication by external identifier, a separate failure log with managed reprocessing. Below, we break down how this is addressed.
What an AI layer on top of bank interfaces provides
The AI layer sits between the service and bank interfaces and does not replace integration, but removes heterogeneity from it. Berlin Group defines a common request framework, but actual bank responses diverge: statement format, payment purpose codes, pagination rules.
The layer brings them to a unified transaction model — date, counterparty, purpose, amount, direction.
Bank transaction classification relies on the payment purpose rather than the category code: banks fill it in as free text and almost never according to a template.
The model labels the flow and sends only low-confidence lines for manual review — on typical statements, more than nine out of ten transactions are parsed automatically.
Automatic statement parsing eliminates manual reconciliation: parsing a monthly statement for one client used to take hours, now it takes minutes, and the time does not grow with the number of connected banks.
Integration resilience is built on failure isolation, not on a single "main" bank.
Each bank is a separate route with its own circuit breaker, timeout, and retry queue: if a participant is unavailable, requests to it are buffered, while the remaining routes respond normally.
This eliminates an entire class of failures where the fall of one bank brought down the overall consent or export scenario.
The response to a balance and transaction list request is fractions of a second on cache and a few seconds on the first call to the bank, while a slow participant does not hold up the others.
The share of automatically parsed transactions remains above ninety percent, and the manual review queue shrinks severalfold: the team sees not a stream of errors, but a short list of exceptions, and expansion to a new bank comes down to describing its specifics rather than rewriting logic.
Methods of connecting to bank interfaces: comparison
The choice of access method is determined by three parameters: how many banks need to be covered, how often the balance and statement are requested, and what happens when a failure occurs on the bank side.
The options differ not only in the effort required for connection but also in the class of failures that falls on our side.
| Option | When it fits | Limitations |
|---|---|---|
| Direct bank connection (regulatory access) | Fresh data and a full set of transactions are needed; the bank is part of the product core | Separate integration for each bank, different request limits, connection timelines depend on the bank |
| Bank aggregator | Broad coverage immediately and a short launch time are needed | Single point of failure, limited set of fields and transactions, statement update delay |
| Hybrid access scheme with cache and routing | Some banks provide the main load, the rest are a long tail | A data normalization layer, update rules, and discrepancy control are needed |
In any option, we bring bank responses to a single internal contract: the application works with a unified model of account, transaction, and consent, while the data source changes by route configuration.
This makes it possible to start with an aggregator and later move key banks to a direct channel without rewriting business logic.
Caching bank data removes part of the load from bank interfaces and smooths over their unavailability: the statement is updated on a schedule, the balance on demand, and on error the last confirmed state is returned with a timestamp.
Routing rules decide which request goes directly, which goes through the aggregator, and when the response is taken from cache.
Stages of implementing AI integration in the banking environment
The work proceeds from inventory to controlled rollout: first we record what is already connected in the Open Banking environment, then we design the flows, and only then do we touch the production environment.
An error in routing account requests is revealed not at the assembly stage, but on real client transactions.
- Integration audit. Inventory of connections: which bank interfaces are used, where consents are stored, what limits apply. The result is a dependency map and a list of bottlenecks.
- Request routing scheme. We define what goes to the model, what is decided by rules, how failures and timeouts are handled. The rules are fixed by specification, not by agreement.
- Account access setup. Roles, scopes, consent lifetimes, logging of every access. Access is granted on a least-privilege basis.
- Testing on real data. Shadow mode on historical transactions and the bank sandbox; discrepancies with decisions of current rules are resolved before rollout.
- Pilot on a share of traffic. We monitor latency, failure rate, and log completeness. Rollback to the previous scheme is one switch.
- Handover and support. Configurations, flow diagrams, incident response regulations, and the model update procedure.
We hand over not only the working environment but also the procedure for changing it: how to add a scenario, how to roll back routing rules, who responds to an incident.
Access policies, diagrams, and handover documentation
A ready integration is not only working data exchange. Without an access matrix and operating regulations, the solution lasts until the first certificate rotation or a change on the bank side.
That is why, along with the system, we hand over artifacts that your team uses to support and develop it independently.
- Connection configurations: test and production environment addresses, client identifiers, mutual authentication certificates, request signing keys, and their rotation procedure.
- Data flow diagram: the full path of a consent request — initiation, user redirect, return, token exchange, renewal, and access revocation.
- Role and access matrix: who is authorized to initiate a payment, read balances and history, revoke consents; separation of read and write permissions, least-privilege access, action log.
- Failure handling regulations: behavior on an expired token, exceeding request limits, and bank unavailability — retry with increasing delay, payment idempotency by operation key, procedure for manually reviewing stuck transfers.
- Integration documentation: description of contracts and exchange formats, a reference of error codes with explanations and examples of valid and rejected requests.
- Support instructions: how to reissue a certificate, revoke access, bring the environment back up after a failure, and within what timeframe to escalate an incident.
- Update procedure for changes in bank interfaces: a set of mandatory checks before rollout and a responsibility matrix.
The artifacts are stored in the repository alongside the code and versioned with it. A change on the bank side becomes an edit to configuration and documentation rather than a search for the integration's author — support does not depend on a single person.
Case study: account aggregation with AI request routing
Before
The aggregator polled banks synchronously when the screen opened: each request waited for the slowest participant, and an error on one connection broke the entire account summary.
The share of automatically processed requests remained around 70%, the time to display the balance reached 6–8 seconds, and the share of unsuccessful requests to banks was 12–14%.
Within these failures, different causes were mixed: rate limiting, expired consents, and network interruptions, and the system responded to all of them in the same way — by retrying to the limit.
What was changed
We separated data collection from its display: a background crawl fills the cache, the screen immediately returns the latest known values and updates them as they arrive.
Routing of requests to banks was moved to priority rules — fresh balances go ahead of the queue, history and analytics are fetched later, so a slow bank no longer holds up the others.
Retries were made with increasing delay and handling by failure class: a network failure is retried, an expired PSD2 consent goes to the re-authorization scenario rather than endless attempts. Request keys eliminated duplicates on repeated sends.
After
The share of automatically processed requests grew to 96%, the time to display the balance dropped to 1–1.5 seconds, and the share of unsuccessful requests to banks was 2–3%.
The remaining failures are now classified: the user sees which bank requires re-login instead of a generic loading error. The load on bank interfaces decreased due to caching and smoothed retries, so rate limits stopped being a source of failures.
How direct connection differs from an aggregator
The difference shows up in four places: the depth of the data returned, the freshness of that data, the area of responsibility during a failure, and the amount of work to keep connections alive. Below is how this looks in practice, not in a presentation.
Data depth. A direct connection returns everything the bank itself publishes: payment purpose, merchant category, recurring income, balance, and limits for each account.
An aggregator brings dozens of banks to a common form — and the common denominator is always poorer: non-standard fields are lost, categories are recalculated according to its own model, and some attributes are available only from a certain access level.
Freshness. A direct connection updates data by event — the picture at the moment of the request.
An aggregator more often works on periodic polling: account movements are pulled on a schedule and sit in an intermediate storage, so between the real transaction and its appearance for you, anywhere from a few dozen minutes to hours pass. For scoring and analytics this is fine; for payment confirmation it is not.
Responsibility for failures. With a direct connection, an incident is localized at the junction with one specific bank: it is clear whose response did not arrive, diagnostics take minutes, but negotiations and on-call duty are on your side.
With an aggregator, a single point of failure appears: if it is unavailable, all banks are unavailable at once.
At the same time, investigation goes through a third party, and the typical scenario is mutual finger-pointing: the aggregator says the bank did not respond, the bank claims it saw no requests.
Keeping up to date. Banks change consent schemes, customer confirmation requirements, certificates, and response formats. With a direct connection, the amount of work grows linearly with the number of banks, and every edit is your release. An aggregator takes this on itself, but updates arrive on its schedule, outside your control.
Therefore, in practice, a hybrid is more often assembled: an aggregator such as Salt Edge covers the long tail of banks at the start, while direct connection is placed where full field depth and predictable response latency are needed.
Technical concerns around AI in banking data
Open Banking is built on third-party interfaces, so uncertainty is the norm: a client notices a discrepancy in a statement before monitoring does. Before starting, we fix the system's behavior in non-standard situations — below are the four concerns that are raised first.
What happens if a bank stops responding?
Requests go through a queue with retries and increasing delay, so the unavailability of one bank does not stop the other connections. The transaction is marked as pending confirmation, and repeated delivery does not create duplicates — an idempotency key by operation identifier. When the bank returns, the export catches up, and discrepancies go into a separate review log.
Who is responsible for the quality of transaction recognition?
We are, and this is fixed in the acceptance criteria. Each match receives a confidence score: above the threshold it goes automatically, below it goes to manual review, not into a report.
We calculate category accuracy on a labeled set regularly, so degradation is visible before a client notices it.
What to do with banks not in the set?
Coverage is described by a matrix: direct connection, aggregator, file export. An incomplete set of banks is a matter of priority, not architecture: a new bank is added as a separate module, and the core and recognition rules are not rewritten.
How is banking data protected?
We do not store credentials — we work on tokens, access is role-based, and every access is logged. Consent is issued with a lifetime and revoked in one step; after revocation, access is closed immediately. The channel and storage are encrypted, and test environments are isolated from production ones.
Let's discuss the task: an AI layer for Open Banking
To take on an AI layer on top of Open Banking, access to the production environment is not needed.
A test environment of a partner bank, the XS2A specification in your edition, examples of statements in ISO 20022, and a list of decisions currently made manually — on payments, limits, and suspicious transactions — are sufficient.
The first result of the work is not a presentation, but a working vertical slice: one consent, one scenario, one model, and a quality measurement on historical data.
On the customer side, a minimum is needed to start: sandbox access, a contact for the integration team and a security specialist, an anonymized sample of transactions for a sufficient period, and the current consent rules — lifetimes, scope of rights, revocation procedure.
- map of available API endpoints and consent rights: what the bank actually returns and what we build on our side
- data flow diagram from consent to model response, with explicit failure and rollback points
- model prototype on your anonymized data: scoring, transaction classification, statement parsing
- metrics on a holdout sample: completeness, false positive rate, resilience to gaps in data
- policy for anonymization, storage, and access control for personal data
- pilot plan: load volume, success criteria, stop conditions, and rollback to the previous logic
Describe the task in free form — which processes you want to cover and what is already in the test environment.
We will come back with an estimate of the scope of work, a plan for the pilot launch of the integration, and a list of what will be required from the bank and your team.
