Every open banking project we have worked on started with the same estimate: "we just need to expose a few APIs." The API is rarely the hard part. The time goes into the things around it, and teams consistently underestimate four of them.
Consent is a product, not a checkbox
A consent record is not a boolean on a user row. It has a scope, an expiry, a grantor, a grantee, and a full history of every change — because when a customer or a regulator asks "who had access to this, and when", you need to answer precisely, including for consents that have since been revoked.
That means consent needs its own data model, its own lifecycle, and its own audit trail from day one. Retrofitting it into a system that treated consent as a flag is expensive, because every integration that read that flag has to be revisited.
Partner onboarding is where the calendar disappears
Exposing an API takes weeks. Getting a third party certified, sandboxed, credentialed and into production takes months, and most of that time is not yours to control. Build the sandbox and the self-serve documentation early, because every week a partner spends waiting on your team is a week added to the integration.
The practical move is to make onboarding self-serve before you need it: published specs, a sandbox with realistic test data, and credentials a partner can generate without emailing anyone.
Versioning is a commitment you cannot take back
Once a bank or a fintech integrates against your API, you own that contract more or less permanently. Partners do not upgrade on your schedule. Plan for several versions running at once, and decide early how long you will support each one — because deciding later means deciding under pressure from whichever partner shouts loudest.
Observability is a compliance requirement, not an optimisation
In most engineering projects, monitoring is something you add once traffic justifies it. In regulated financial infrastructure, you need to be able to reconstruct what happened to a specific transaction on a specific date, often long after the fact. That is a design constraint on your logging and retention from the first commit, not a dashboard you bolt on in month six.
What this means for your estimate
If you are scoping an open banking build, assume the API surface is a minority of the work. Consent, onboarding, versioning and auditability are the majority, and they are the parts that are painful to add later.
The teams that ship fastest are the ones that treat those four as first-class features in the first sprint, rather than as compliance tasks to be handled before launch.
