A control plane for financial connectivity
You integrate one normalised API and event model. The providers underneath run on your own contracts and credentials, and changing them does not mean rewriting your application.
Eight layers
Each layer exists because it is otherwise rebuilt inside the application, once per provider, by a team that would rather be building the product.
| Layer | What VEREA does | Why it matters |
|---|---|---|
| Connectivity | Reach banks, brokers and wealth platforms through several upstream connectivity providers, using your own provider contracts and credentials where each provider’s terms allow it. | Coverage stops being a property of a single vendor relationship, and each relationship stays yours. |
| Capability graph | Map institution, country, account type, provider and product capability against each other. | Turns "supported" into a precise answer for the connection in front of you. |
| Routing | Select the provider for each connection from capability, health, history, latency, data quality, cost and your policy. | Providers become interchangeable instead of load-bearing. |
| Lifecycle | Normalise consent, authentication, re-authentication, errors and webhooks into one state machine. | Provider-specific state machines leave your application. |
| Canonical data model | Expose accounts, balances, transactions, positions and liabilities in one shape. | You build once against a model that survives provider changes. |
| Identity | Link equivalent financial accounts across provider connections to one canonical account. | Migration and duplicate detection stop being data-cleaning projects. |
| Observability | Centralise connection health, failure reasons, latency and data freshness across providers. | Connectivity becomes an operable platform rather than hidden middleware. |
| Provenance | Record the provider, institution, connection, timestamp and source record behind material fields. | Regulated decisioning, reconciliation and AI all need to know where a number came from. |
The shape of it
Your application talks to one interface. The control plane resolves a route to a provider, and the provider reaches the institution that holds the account. The highlighted path is the route chosen for one request.
One connection lifecycle
Providers disagree about what a connection is doing and what to call it. VEREA collapses those differences into a single set of states and emits the same event model whichever provider served the connection.
Your application subscribes once and handles one vocabulary. Re-authentication, temporary unavailability and revocation stop being provider trivia and become states you can design for.
type ConnectionState =
| "created"
| "authorized"
| "connected"
| "syncing"
| "synced"
| "needs_reauth"
| "temporarily_unavailable"
| "provider_error"
| "revoked"
| "expired";What routing weighs
Routing is not a failover switch. The value is control over fragmentation: knowing which route can actually deliver the capability you asked for, at this institution, in this country, for this account type.
Your own policy is one of the inputs. If you need a specific provider for a specific segment, that is a routing rule rather than a rebuild.
- Country
- Institution
- Account type
- Required capability
- Provider health
- Historical success
- Latency
- Data quality
- Cost
- Your own routing policy
Canonical model, in order
The model widens deliberately. Banking has to work before wealth is worth attempting, and wealth has to work before the wider financial graph means anything.
- Banking first
- Accounts, balances and transactions.
- Then wealth
- Investments, positions, securities and pensions.
- Then the wider graph
- Liabilities, loans, mortgages and business finance.
Who holds the provider contracts
A control plane that forces you to depend on its own supplier relationships has replaced one lock-in with another. By default the contracts and the credentials stay with you.
Your provider contracts, your keys
The default. You hold the agreements and the credentials, and where the provider’s terms allow it, VEREA uses them on your behalf to route across providers, normalise what comes back and give you one operational view. Your commercial position stays with you.
Agreements held by VEREA
Not part of the first product. Some teams will want a provider they have no relationship with, and VEREA may later hold agreements for that case, but only where the provider permits the arrangement and once the authorisation it requires is in place.
Technical-service architecture
The intent is that any regulated step is performed by the regulated party, with VEREA supplying the infrastructure around it: processing data on your instructions and never presenting it to your end users. Where exactly that perimeter falls in each market is something we are still working through. VEREA is designed as infrastructure, not as a provider of regulated financial services.
What this is not
VEREA is not another bank aggregator, and it is not trying to out-build the providers at raw connectivity.
It is the layer above them: the capability graph, the routing decision, the normalised lifecycle, the canonical identity and the operational record of what actually happened. The product is in design and in early access, and the descriptions above are of that design.
See it against your own institutions
We look at the institutions and countries that matter to you against more than one provider, and write up the provider dependence, the failure handling and the operational duplication we find.