Insights · 11 min read
Open banking lets third parties read bank data and start payments through APIs. What it takes to build a compliant open banking or open finance platform, from scope and regulation to cost and team.
By GGP Editorial
Open banking is the practice of letting third-party companies read bank account data and start payments through APIs, with the account holder's permission. If you have been asked to build a platform that pulls balances and transaction history from many banks, or that starts account-to-account payments, you are looking at an open banking build.
This guide covers what that build actually involves, which regulation you have to satisfy, what it costs, and where scope usually grows. I am writing it for founders, product leads and banks planning a real project, not for people researching the concept. GlobeSoft builds fintech systems, and we have delivered trading platforms, payment systems and financial management software for clients in Brazil, South Africa, Singapore and the US. You can read about our fintech development work for more context.
An open banking platform is usually one of three things.
The first is a third-party provider that consumes bank APIs. In Europe and the UK this role splits into an AISP (account information service provider), which reads data, and a PISP (payment initiation service provider), which starts payments. A lender using account data for affordability checks is an AISP use case. A checkout that moves money straight from a bank account is a PISP use case.
The second is a bank-side interface that exposes the bank's own accounts and payments to third parties through a standard API. If you run a bank, this is your side of the equation. We wrote about the broader build for banks in our piece on banking software development.
The third is an aggregator or middleware that sits between many banks and many apps, normalizing dozens of different APIs into one. Most of the companies we talk to want the first or the third.
The build looks different for each role, so settle this before you write any code.
The use cases are concrete, and each one changes the scope.
Lending and credit decisioning. Lenders use open banking to read real income and spending data instead of asking for payslips and bank statements. If this is your use case, you usually pair account data with identity and KYC checks.
Personal finance management. Aggregation apps show a customer's accounts from different banks in one place and categorize spending.
Account-to-account payments. Merchants and platforms start payments straight from the customer's bank account. The cost per transaction is lower than cards, which is why UK merchants have been moving to "Pay by Bank".
Accounting and bookkeeping. Bank feeds power reconciliation in accounting products, which is why accounting tools are among the heaviest users of open banking.
Business payments and treasury. Treasury teams and B2B platforms use open banking for balances, reconciliation and supplier payments.
Each of these is a different product. A lending data API, a consumer aggregation app and an account-to-account checkout share almost no front end and only part of the back end.
Here is the core set of modules, with what each one does and why it matters.
| Module | What it does | Why it matters |
|---|---|---|
| Bank API connectors | Connect to each bank or aggregator and normalize the data | The largest part of the work and the main cost driver |
| Consent management | Record what the customer approved, for how long, and let them revoke it | Consent is the legal foundation in every market |
| Strong customer authentication | Verify the customer during the redirect flow | Mandatory under PSD2 and mirrored in most other markets |
| Data normalization and storage | Turn different bank formats into one schema and store transactions | Banks format the same data differently |
| Payment initiation | Start account-to-account payments and reconcile results | The revenue feature for many fintechs |
| Security and monitoring | Encryption, fraud checks, API monitoring, rate limits | Open banking platforms are a known attack target |
| Admin and reporting | Support tools, consent audit logs, dashboards | Banks and regulators both ask for audit trails |
If you build only the happy path and skip consent management or monitoring, the platform will fail a bank review or a regulator audit. That is the single most common reason open banking projects get sent back to the drawing board. We wrote a longer piece on the security side here: security requirements for fintech platforms.
Open banking is a regulated activity in most of the markets that matter. The rules decide what you can build, who can use it, and how long go-live takes.
PSD2, adopted in 2015 and applied from September 2019, created the AISP and PISP roles and forced banks to open APIs. In the UK the nine largest banks were additionally ordered to open their data from 2018 under a Competition and Markets Authority ruling, with the FCA licensing AISPs and PISPs. The UK has since pushed account-to-account payments under the "Pay by Bank" name, and that channel has grown quickly because it costs merchants less than card payments.
The US took a different route. Section 1033 of the Dodd-Frank Act gives consumers the right to access their financial data. The CFPB issued its final Personal Financial Data Rights rule in late 2024, with compliance phasing in from 2026. Instead of a licensing regime, the US relies on data aggregators and technical standards to move the data.
Brazil's central bank runs the largest open finance program in the world. It passed 100 million connected accounts and 150 million active consents by 2026, and PwC estimates open finance could add roughly R$42 billion in new revenue to the sector by the end of 2026. Brazil is also where open finance connects directly to Pix, the country's instant payment rail.
Australia's Consumer Data Right started in 2019. Canada has published a consumer-driven banking framework and expects implementation around 2026. Nigeria, Mexico and several other countries run their own frameworks.
| Market | Model | Key requirement |
|---|---|---|
| EU | PSD2 licensing (AISP/PISP) | Bank APIs, strong customer authentication, regulator authorization |
| UK | CMA order plus FCA | Open Banking Standard, FCA registration |
| US | CFPB Section 1033, aggregators | Consumer data rights, phased compliance from 2026 |
| Brazil | Central bank open finance | Mandatory API phases, Pix integration |
| Australia | Consumer Data Right | Accredited data recipients |
The practical point is that regulation shapes scope. In the EU and UK you apply for authorization or register as an agent. In the US you usually build on an aggregator and manage data rights. In Brazil you follow the central bank's phases. You cannot design the platform before you decide which market you are entering.
Map the exact use case (read data, start payments, or both), the markets, and the banks you need. This is where the MVP gets defined. Most teams over-scope at this point.
Decide whether to apply for authorization or build on an aggregator such as Plaid, TrueLayer or Yapily, or the local equivalent in your market. This decision changes the whole architecture and the timeline.
An open banking platform is integration-heavy. It needs an API gateway, a connector layer, a consent store, an authentication flow, a data model and a secure vault. We wrote about fintech architecture in more detail here: fintech application architecture.
This is the real work. Each bank API has its own quirks, error messages and rate limits. Connectors are built, tested against the bank's sandbox, and maintained forever, because banks change their APIs without warning.
Build the redirect flow where the customer authorizes access, plus the re-authentication and revocation paths. This has to match the regulator's specification exactly.
Encryption at rest and in transit, tokenization, audit logs and fraud monitoring. For EU and UK builds you also pass conformance tests against the technical standard.
Bank sandboxes, conformance suites and penetration testing come first, then a limited launch before full scale.
Cost is driven by four things: how many banks you connect to, whether you license or use an aggregator, how much you build versus buy, and where your team sits.
These are the ranges we see across real projects. They are not quotes.
The three biggest line items are connectors, compliance and security. Maintenance runs about 15 to 20 percent of the build cost per year, mostly because bank APIs keep changing.
The largest cost lever is the build-versus-buy decision on connectors. Using an aggregator removes a large amount of work but adds per-call fees and a dependency. Owning your connectors is cheaper per call and gives you control, but it takes longer. We explain fintech cost drivers in more detail here: how much does it cost to build a fintech app. For a rough estimate on your specific scope, try our software cost calculator.
| Path | What you get | Trade-off |
|---|---|---|
| Build on an aggregator | Fastest MVP, no bank-by-bank work | Per-call fees, less control, data passes through a vendor |
| Build your own connectors | Full control, lower marginal cost | Longest timeline, ongoing maintenance |
| License a platform | Compliance handled, features out of the box | Expensive, less flexible |
Most startups start on an aggregator and build connectors only for the banks that matter once volume justifies it. Banks and larger fintechs usually own their infrastructure.
An aggregator-based, read-only MVP takes three to five months. A licensed AISP or PISP with its own connectors takes six to twelve months, and the authorization application runs in parallel. A full multi-market platform takes twelve months or more. Regulatory approval is often the longest item and it sits outside your control, so start it first.
It depends on the market and your role. In the EU and UK you generally need authorization as an AISP or PISP, or you operate through an authorized provider. In the US there is no license; you build on aggregators and comply with the CFPB's data rights rule. In Brazil you follow the central bank's phases. Confirm the current rules with local counsel before you commit, because this changes.
Open banking covers payment accounts and payments. Open finance extends the same idea to other products such as savings, credit, investments, insurance and pensions. Brazil uses the term "open finance" because its program spans more than bank accounts.
For many use cases, yes. Aggregators such as Plaid, TrueLayer and Yapily handle the bank connections and much of the compliance plumbing. You trade per-call fees and some control for a much shorter time to market. For a read-only app, an aggregator is usually the right call.
Expect about 15 to 20 percent of the initial build cost per year. Most of it goes to keeping connectors working as banks change their APIs, plus security and compliance updates.
Open banking platforms fail on two things more than anything else: under-scoped consent and compliance work, and under-estimated connector maintenance. If you are planning one, the most useful thing you can do is fix the market, the use case and the build-versus-aggregate decision before you start.
GlobeSoft has built trading systems for brokers across multiple markets, payment and financial management systems, and fintech platforms for clients in Brazil, South Africa, Singapore and the US. You can see one of those builds in our multi-market trading system case study. If you are planning an open banking or open finance product, we can help you define the scope, architecture, compliance path, timeline and budget.
Tell us what you are building and where you are today. We typically reply within 24 hours.
