Give each customer a EUR virtual IBAN that converts to USDC
Virtual accounts · EUR
Provision a dedicated EUR virtual IBAN per account, attribute each incoming SEPA payment by its reference code, and convert the received EUR into USDC on a supported chain – through one API, without building custody or FX yourself.
Talk to us
Read the API documentation
The attribution ledger
Follow incoming SEPA payments from many payers to the right accounts.
Receiving details
Each account gets its own receiving details
Its EUR IBAN converts incoming euros into USDC, and comes with the reference the payer quotes on their transfer. You show the payer both.
The virtual bank account guide
The account and party model in the Finance API
Credit 1 of 4
Maria’s client pays her invoice
Each payer sends a SEPA transfer with the IBAN, the amount and, in the remittance field, the referenceCode. Maria’s client quotes VF-MARIA-8842, so the credit is attributed to Maria’s account.
Per-seller receiving details on Payment platforms
Credit 2 of 4
The code attributes the credit, not the name
That code is what attributes an incoming EUR credit to the right account, so reconciliation does not depend on name matching.
Credit 3 of 4
Every account matches on its own code
Account C’s payer quotes VF-CLINIC-0473, and the credit is attributed to account C the same way.
Credit 4 of 4
No reference: manual handling
Attribution relies on the referenceCode being present in the incoming transfer. This EUR 75.00 credit has none, so it goes to manual handling instead of to an account.
Conversion
The attributed EUR converts to USDC
The received EUR is converted to USDC and credited on the account's chain (Base here), with the full trail exportable.
Verification, partner setup and funding run separately from the attribution shown here, and available assets and routes depend on configuration.
Current limitations
- Virtual IBANs issued through this flow are EUR pay-in accounts. USD pay-ins use US receiving details, for platforms onboarded for the USD lane.
- Settlement timing depends on the SEPA rail, compliance checks on the incoming payment and onchain execution – it is not guaranteed instant.
- Attribution relies on the referenceCode being present in the incoming transfer; unreferenced credits need manual handling.
- Supported conversion targets and chains are limited to the assets and chains listed above.
Roadmap
Being added
- USD by wire and more payout currencies are being added. International payouts by SWIFT are available on request.
- Additional pay-in currencies on the virtual account surface.
Routes for paying outside SEPA
Also in USD
Get paid from US banks too
Payers in the US can pay your customers from their own bank. Each customer gets US receiving details of their own, and what arrives lands as USDC, in the same balance as their euro payments. The USD lane opens once your platform is onboarded for it, with an approved KYB.
Back to Virtual accounts: USD and EUR receiving details together
Setting up receiving details
How is an incoming SEPA payment matched to the right account?
By the referenceCode returned when the virtual IBAN is provisioned. The payer quotes it in the transfer reference, and the credit is attributed to that account. Matching does not rely on the sender name, which is what usually breaks reconciliation on shared collection accounts.
Which fields come back when the virtual IBAN is created?
iban, bic, bankName, beneficiaryName and referenceCode, alongside the virtual bank account id. Those are the fields you surface to whoever is sending the EUR.
How fast does the EUR arrive as USDC?
It depends on three things you should model separately: the SEPA rail the payer used, compliance checks on the incoming payment, and onchain execution on the target chain. We do not promise a guaranteed instant settlement time.
Which chains and stablecoins are supported?
Incoming EUR converts to USDC, EURC, USDT or USDS, on the chains configured for your account (Base, Ethereum, Polygon, Avalanche and Solana). Receiving-account coverage rolls out per chain, so confirm yours with Venly. Set the target on the account and the virtual bank account request.
Do we need our own licence to use this?
It depends on your role, your flow and your jurisdiction. Some platforms hold their own CASP/VASP/MSB permissions and use Venly as a technology provider; others operate with regulated execution running through licensed partner infrastructure. We will map your specific model with you rather than tell you no licence is needed.
Is Venly Finance MiCA authorized?
Our own licences are in flight. Until they land, regulated legs run on licensed partner rails today. We do not present the licences as complete.
Is this the same as the Venly wallet product?
No. Venly Finance is the payment and settlement layer – parties, accounts, virtual IBANs, transfers and conversion. It runs on Venly wallet infrastructure for custody, key management and signing, but they are distinct products.
Fit
Good fit · not a fit
Good fit
Not a fit
- PSPs and payment platforms adding a stablecoin settlement option to an existing EUR payout flow
- Marketplaces paying sellers who want USDC instead of a local bank transfer
- Fintechs that need per-seller EUR collection accounts with automatic reconciliation
- Teams that want conversion handled at the fiat edge rather than building custody and FX themselves
Adding a USDC settlement option to merchant payouts
Seller payouts to a bank or a wallet
The screens a fintech ships on these receiving details
- Consumer-facing retail onramps or single-user wallet top-ups
- Pay-ins in currencies other than EUR and USD, GBP included: this flow does not issue those receiving details
- Card-present acceptance or acquiring; this is a bank-rail pay-in surface
- Anyone expecting Venly to assume their own licensing obligations
Next step
Bring your reconciliation file
Show us how incoming payments are matched today. We will map it to accounts, virtual IBANs and conversion in one session.
Playbook for migrating a virtual account provider
Talk to us
Read the API documentation
When a virtual IBAN is issued
A virtual IBAN is issued to a verified account. The account needs a linked account-holder party with verification cleared before its receiving details are issued; while verification is pending, issuing waits. After that, each incoming credit is matched by its referenceCode.
SOC 2 Type 2 certified. Our own licences are in flight and flows run on licensed partner rails today.