Migrating your virtual account provider: a parallel-run playbook

By Venly Finance | August 20, 2026

How to move EUR and USD virtual accounts to a new provider: contract structure, the re-verification you cannot avoid, parallel runs, reconciliation acceptance tests and the diligence questions to ask first.

Changing the provider behind your virtual accounts is not an API migration. It is a customer migration, a reconciliation migration and a compliance-evidence migration that happens to involve some endpoints.

Teams discover this in the wrong order. The integration gets re-pointed in a sprint, and then eighteen months of ledger history, a folder of KYB evidence and several hundred payers who still have the old IBAN in their accounting system turn a two-week project into two quarters.

This is the playbook we use with platforms moving a EUR or USD collection setup onto venly finance, written so it works even if you move somewhere else.

Start with the contract, not the code

Before anything technical, answer one question: who does your end customer have a contract with?

Providers structure this differently, and it is usually published. Noah, for example, documents two compliance models. Under the Reliance Model, aimed at businesses that hold their own licences, you run KYC and share simplified customer data by API, and the customer relationship stays with you. Under the Standard Model, aimed at businesses without the relevant licensing, Noah's documentation states that Noah enters a direct contractual relationship with your end customers, with terms acceptance completed in a hosted onboarding session (api.noah.com, compliance overview, verified 20 August 2026).

Neither design is wrong. The Standard Model is exactly what an unlicensed business should want: someone else's regulatory framework carrying the weight. But it changes what a migration is. If your customers are contractually attached to the provider, moving them means re-onboarding them, and re-onboarding is the step that leaks customers.

The same documentation carries a second constraint worth checking against your roadmap: Noah's docs state that USD payments are not available via the Reliance Model. A licensed business that wants USD is pointed at the Standard Model, which is where the direct customer relationship sits. Currency coverage and contract structure are not independent variables.

Whoever you are evaluating, ask for the same two answers in writing before you scope anything: who contracts with my end customer, and which currencies are available under that structure.

What a migration cannot avoid

No provider change is invisible to your customers, and anyone who tells you otherwise is selling.

A new provider, ours included, has to run its own onboarding. KYB on your entity, and depending on your licensing status, the flow and the jurisdiction, verification or re-verification of the parties behind the accounts, fresh screening and new terms somewhere in the chain. Evidence gathered by the outgoing provider is usually not reusable, because the institution taking on the risk is the one carrying the obligation.

What contract structure changes is not whether verification happens. It changes who your customer is verified by, whether it can run while the existing setup is still live, and whether the customer has to accept a third party as their counterparty in order for you to keep getting paid. That is the difference between a scheduled compliance workstream and a cutover that leaks customers.

What actually breaks

Four things, none of them the API.

• Payer instructions. Every payer who has your customer's virtual IBAN saved in their ERP, their bank template or their treasury workflow. This is the slowest and most customer-facing part of any fiat-edge migration, and it does not respond to engineering effort.
• Reconciliation keys. Your ledger is keyed on the old provider's transaction identifiers, fee shapes and settlement batches. Historic reconciliation, dispute trails and finance reports read against a schema that stops being produced.
• Compliance evidence. KYB packs, screening results, travel-rule records and audit logs live in the provider's systems. Your auditor asks for them under your name, not theirs.
• Operational knowledge. Which corridors clear same-day, which counterparties trigger review, what a payout really costs once fees, spread and failures are counted. None of that transfers in an export.

The parallel run

Do not cut over. Run both providers against the same ledger until the new one is boring.

| Phase | What happens | Exit criterion | | --- | --- | --- | | 1. Shadow | New provider integrated in mock mode, then staging. No live volume. Ledger writes both shapes. | Reconciliation output matches on synthetic flows | | 2. First corridor | One currency, one flow, lowest-risk customer segment. New accounts issued alongside the old ones. | 30 days, no unmatched credits, finance signs off | | 3. Payer re-pointing | New account details pushed to payers per customer, old accounts stay open and monitored | Inbound volume on old accounts below an agreed threshold | | 4. Corridor expansion | Remaining currencies and rails moved one at a time, in volume order | Each corridor passes the phase-2 test | | 5. Drain and retire | Old accounts monitored, residual credits swept, provider contract wound down on notice | Zero inbound for a full settlement cycle |

Two rules make this work. First, one corridor at a time: if something breaks you want a bounded blast radius, not a whole book of business. Second, keep the old accounts open long past the point where they feel necessary. A payer who pays the old IBAN in month four is a reconciliation exception, not an incident, as long as the account still exists.

Make reconciliation the acceptance test

The only honest signal that a migration worked is that finance stops noticing it.

Run both providers' data into one internal ledger with your own identifiers, not theirs. Every incoming credit should carry a key you generated. On venly finance, that is the `referenceCode` on a per-customer virtual account: an incoming credit arrives already attributed to the right customer, so there is no matching engine and no unmatched queue to reconcile at month end. If your new provider cannot attribute inbound automatically, you are not migrating a rail, you are inheriting a matching problem.

Concretely, for each corridor, sign off on:

• Every credit in the period attributed to a customer without manual intervention
• Fees decomposed the same way in your ledger as in the provider statement
• Failed and returned payments visible with a reason code, not just a missing amount
• An export your auditor can read without the provider's dashboard

Protect the exit while you build the entrance

The reason to migrate is usually that the previous setup made changing hard. Do not rebuild that.

Three properties decide whether your next migration is a routing change or another two quarters:

1. Your customers are yours. The end customer should be an object in your own account structure, and your provider should be your vendor rather than your customer's counterparty. This is what allows a second account to exist alongside the first while the commercial relationship stays yours. Onboarding and verification requirements still apply under the receiving institution; what they do not require is handing your customer to someone else's contract. 2. Regulated execution is diversified. When one provider carries the licence, the accounts, the corridors and the customer terms, all of them move together. Spreading execution across several licensed partner institutions means a change in one partner's terms re-routes a corridor instead of re-platforming your business. 3. Approvals are yours, in endpoints. Who can release a payout should be enforced by the API and exportable as an audit trail, not configured in someone's dashboard and screenshotted for your auditor.

What to ask before you sign anything

A short diligence list that surfaces most future pain:

• Who contracts with my end customers, and what happens to that relationship if I leave?
• Which currencies are available under my licensing status, specifically?
• Is inbound attributed per customer automatically, and by what key?
• Can I export a full compliance and transaction record in a format my auditor accepts, on demand?
• Which licensed institutions execute each regulated leg, and what happens if one of them changes terms?
• Can I run this alongside my current provider during migration, or is it a cutover?
• What is the notice period, and what happens to open accounts during it?

Where venly finance fits

We built the fiat edge to be migrated onto and, if it ever comes to it, away from. EUR and USD virtual accounts issued per customer under a party model you own. Inbound attributed by `referenceCode`, so pay-in reconciles itself. Conversion into and back out of USDC, EURC, USDT and USDS in the same API as the payout. Regulated money movement executed through licensed partner institutions across SEPA, USD wire, USD ACH, GBP FPS and SWIFT, so a corridor can move without a re-platform. Approval separation on ramp requests, with audit export.

We are also plain about the trade: our payout footprint is narrower than providers built around wide local-method reach, we do not settle Bitcoin, and our MiCA CASP application is in progress while every regulated leg executes under a named licensed partner. If your growth depends on mobile money in dozens of markets, keep that provider and move only the EUR and USD core. Running both is a legitimate destination, not a half-measure.

The side-by-side, with sources and dates, is in venly finance vs Noah. The commercial structure, line by line, is on pricing. And engineers can model the whole parallel run in SDK mock mode before anyone has a commercial conversation.