Schedule a demo

Pick a time with our team. The scheduler is provided by Calendly and sets its own cookies.

Prefer email? support@coriunder.com

We use your details to arrange your demo. Read our Privacy Policy.

IBAN Accounts

A real account number for every customer on your platform.

Funds are held by the partner bank or EMI that issues the IBAN. Issue IBANs against customer and merchant accounts across the banking providers you choose, see the balances in real time, detect incoming deposits and pay out to stored beneficiaries. The account is theirs. The provider behind it is your decision, and it can change.

Schedule a demo Back to Wallet

IBAN and banking providers you can connect

An account, not a ledger entry

A balance a customer cannot be paid into is a number in your database. An IBAN turns it into something their employer, their customer and their bank can actually send money to.

34+

Providers to connect

Any

Currency you support

Per

Programme provider choice

1

Balance model behind it

What it does

From an account number to money in the balance

Creating the IBAN is the easy half. The work is what happens when money arrives, when it needs to leave, and when somebody has to answer for where it went.

1Request an IBANConsumer programme
Account
Customer #40218
Provider
Provider A
Issue IBAN
2Visible while it opens
CU
Awaiting provider
Requested 10:02 · Customer #40218
Opening
3The number belongs to the account
CUGB•• •••• •••• 4417CustomerActive
MEDE•• •••• •••• 9052MerchantActive

Issue and assign

Create an IBAN against a customer or a merchant account and it belongs to that account from then on. New client accounts are visible while they are still being opened, so nobody has to guess whether a request went through, and the provider behind the account is chosen per programme rather than hard-wired into the platform.

How the wallet holds it
1Deposit detected09:10
+ €1,250.00
SEPA credit · from Northwind Ltd
Detected
2Credited to the right account
GB•• •••• 4417
→
Customer #40218
3Spendable straight awaySame balance
Available balance
€3,480.00
Ledger matches recon

Money arriving

Incoming deposits are detected and credited to the right account without an operator watching a bank statement. The credit lands in the same balance the rest of the platform reads, so a customer who was paid at ten past nine can spend at eleven, and reconciliation sees the same movement your ledger does.

How it reconciles
1Pay a stored beneficiary
LU
Lumen GmbH
DE•• •••• 2210 · on file
€8,400.00
2Checks before anything moves
Admin risk reviewFirst transferPending
Limit checkPer programmePass
AML screeningPass
3Released once review clears
Held→Approved→SentSame payout path

Money leaving

Outbound payments go to stored beneficiary accounts through the same approval path as any other payout, with limits and an AML check before anything moves. A beneficiary gets an admin risk review before its first transfer, which is the moment that actually matters.

Payout requests
1Choose the fee modelPer programme
FlatFixed amount
PercentOf amount
BothFlat + %
2Corporate programme
€120,000.00 transfer
Flat 5.00 + 0.25%
Fee €305.00
3Consumer programme
€50.00 transfer
Flat 0.50 · no percentage
Fee €0.50

Fees that fit the product

Payout fees are set as a flat amount, a percentage, or both together, per programme. That covers the difference between a corporate account moving six figures and a consumer account sending fifty euros, without needing two products.

Fees and settlement
1Each programme, its own bank
Corporate→Provider AOwn credentials
Consumer→Provider BOwn credentials
Marketplace→Provider COwn credentials
2Add a providerConfiguration, not a rebuild
Provider D · API key ••••••
Add
3Open accounts keep working
Open accounts
12,480
Still on their current provider
Unchanged

One provider, or several

Providers are configured per programme with their own credentials, so different customer segments can sit behind different banks. Adding a provider is a configuration exercise rather than a rebuild, and the accounts already open keep working.

See the integrations
In the box

What comes with IBAN accounts

Account issuing

An IBAN assigned to a customer or merchant account and owned by it.

Multi-currency

Balances held and reported per currency, not converted behind your back.

Deposit detection

Incoming credits matched to the right account automatically.

Beneficiary payouts

Stored bank accounts, with a risk review before the first transfer.

Flexible payout fees

Flat, percentage or a combination, configured per programme.

Approval and AML

The same gate every outbound payment on the platform passes through.

Status visibility

Accounts still being opened are visible rather than silently pending.

Credentials per programme

Each programme holds its own provider credentials, kept apart.

For your integration

The balance layer, as an API.

The web services portal documents the calls behind the wallet: read a total, request an amount, transfer between accounts and between currencies, request a payout, and pull balance rows. The same operations your own product will make, with the request and response for each one.

  • Balance service
  • Transfers
  • Currency conversion
  • Payout requests
  • Balance rows
  • IBAN accounts
  • Prepaid cards
  • Customers
Web services webservices.coriunder.cloud Open the web services portal

Frequently asked questions

  • Whose IBAN is it?

    It is issued through the banking provider you connect and assigned to the customer or merchant account on the platform. Which provider sits behind a given segment is your decision, set per programme.

  • Can different customers sit behind different banks?

    Yes. Providers are assigned per programme, so a corporate segment and a consumer segment can be served by different institutions while both appear in the same console and the same balance model.

  • How do we know money arrived?

    Incoming deposits are detected and posted to the account automatically, and the movement appears in the balance rows like any other. Nobody has to read a bank statement to find out.

  • What stops a payout going somewhere it should not?

    Beneficiaries are stored rather than typed each time, and a new one gets an admin risk review before its first transfer. Every outbound payment then passes the standard approval and AML check.

  • Can we charge for payouts?

    Yes, as a flat fee, a percentage, or both, configured per programme so different account types can carry different pricing.

  • What if we want to change provider later?

    The provider sits behind an adapter layer rather than being wired through the product, so adding or changing one is configuration. Talk to us about the specific migration, since open accounts need a plan.

Still have a question?

Give your balances an account number.

We will map your segments to providers and show you the flow end to end.

The wallet it sits on Talk to our team

Provider availability depends on your programme and jurisdiction. Talk to our team about the corridors you need.