Skip to main content

One API. Every financial connection.

Integrate financial connectivity once. Change what runs underneath without rewriting your application.

VEREA is a control plane above the connectivity providers that reach banks, brokers and wealth platforms. Your application asks for a capability; VEREA decides which provider answers.

Early access for fintech, wealth and lending teams that depend on connectivity providers. Design partner programme open. United Kingdom, Spain and Portugal first.

One request from your application enters the VEREA control plane, which selects one route across several connectivity providers to reach the institution that holds the account. Your applicationVEREAcontrol plane

Today, one provider becomes the architecture

Every connectivity provider brings its own API, consent flow, schema, webhook model, error semantics and contract. A team that outgrows the first one accumulates integrations rather than infrastructure. The cost stays invisible until a coverage gap, a failure mode or a migration exposes it, and by then the provider is load-bearing.

With VEREA, providers become infrastructure

VEREA is designed to run on your own provider contracts and credentials, through one interface. You describe the customer, the country and the institution. VEREA resolves the route, normalises the connection lifecycle, keeps account identity stable across provider changes and records where every material field came from. When the provider underneath changes, your code does not.

Ask for a capability, not a provider

The question a product team should be answering is which financial capability it needs, not which aggregator to integrate. VEREA turns the second question into an operational decision it makes on your behalf.

The sample below is illustrative. Institution identifiers are opaque and stable; the provider that served the connection is reported, never assumed by your code.

Open a connection
const connection = await verea.connections.create({
  customerId,
  country: "ES",
  institution: "inst_8f3k"
});
The highlighted line is the only place an institution appears. Which provider serves it is VEREA's decision, taken against capability, health, cost and your own policy.
Read from it
const accounts = await verea.accounts.list(connection.id);
const [account] = accounts;

const transactions = await verea.transactions.list(account.id);

Canonical resources

/accounts
Every linked account under one shape.
/balances
Current and available amounts, with their timestamp.
/transactions
One transaction model across institutions.
/positions
Holdings on investment and brokerage connections.
/liabilities
Credit, loan and mortgage obligations.

Banking comes first, then investments, securities and pensions, then the wider financial graph.

Where connectivity is already a platform dependency

VEREA is built for teams that already pay the engineering and operational cost of financial connectivity, not for teams making their first integration.

  • Wealthtech

    Banks, brokers and pensions in one model, and provider changes that do not break account identity.

  • Lending

    Transactions, balances and liabilities with consistent semantics and a source for every field.

  • Financial AI

    Governed access for agents: permissions, scope, provenance and an audit trail on every read.

Where we are

VEREA is in design and in early access. Before committing to a large build, it needs to establish three things: that providers permit the model, that teams will pay for it, and where coverage actually differs between providers.

We say this plainly because the people we want to talk to can tell the difference. If connectivity is already a platform problem for you, the connectivity audit is the fastest way to find out whether we are useful to each other.

Start with a connectivity audit

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.