Contact us
/// vIBAN · Reconciliation

Reconciliation by construction

When every payer pays into their own IBAN, an incoming payment can only mean one thing. The matching problem does not get solved — it stops existing.

Contact usAll products
1
Master account
Per-payer
Automatic reconciliation
Bulk
IBAN issuing
Tagged
Rent · subs · payouts
/// 01

One account, thousands of addresses

Behind the scenes there is one master account. On the surface, each payer, tenant, or subscriber gets a dedicated virtual IBAN. Money lands in the master account either way — but it arrives pre-labeled with who sent it and what it is for.

/// 02

Built for platforms

Issuing happens in bulk, not one form at a time — a marketplace onboarding a thousand sellers mints a thousand IBANs in one operation. Purpose tags keep flows separated: rent here, subscriptions there, marketplace payouts in their own lane — so every entity in a platform gets its own reconcilable account number.

  • [ 01 ]Bulk issuing via console or API
  • [ 02 ]Purpose-tagged IBANs for clean flow separation
  • [ 03 ]Per-payer history without a matching engine
/// Integration

Issue to statement, five steps.

  1. [ 01 ]

    ISSUE

    Mint a vIBAN per payer — one by API, or 2,400 by CSV with a review step.

  2. [ 02 ]

    SHARE

    Each payer pays their own IBAN; no reference to mistype.

  3. [ 03 ]

    MATCH

    Credits self-identify by construction — 99.6% auto-reconciled in the demo.

  4. [ 04 ]

    EXCEPT

    The rest lands in a counted exception queue with history attached.

  5. [ 05 ]

    REPORT

    Per-vIBAN statements, CSV and PDF, emailed monthly on the 1st.

/// Features
The full book — every vIBAN, its payer, and today's incoming money.
/// 01

The operator console

One screen holds the whole program: 12,480 active vIBANs, €2.4M routed today, 8,912 credits auto-reconciled. Every row shows the IBAN, who it belongs to, its purpose tag, and today's incoming money. Search by IBAN, customer, or reference; export the book as CSV.

  • [ 01 ]Search across IBAN, customer, and reference
  • [ 02 ]Status per IBAN — active or paused, at a glance
  • [ 03 ]One-click CSV export of the full book
The payer's screen — one balance, a labeled IBAN for every flow.
/// 02

A clean view for the payer

Customers see their master balance and each virtual IBAN beneath it — rent collection, subscriptions, marketplace payouts — each with a copy button and its last payment. Money always lands in the main balance; the tag travels with it.

Bulk issue — 2,400 rows validated, every IBAN previewed before the click.
/// 03

Bulk issue with a review step

A CSV of 2,400 payers uploads, validates — 2,400 valid, 0 errors — and previews the exact IBAN each row will get, reserved from the range at upload and assigned on issue. Configure the range, purpose tag, and reference prefix, then issue the whole batch in one action. The same operation runs over the API.

  • [ 01 ]Source, configure, review — with a draft to save between steps
  • [ 02 ]IBANs reserved up front, so nothing collides on issue
  • [ 03 ]A webhook per issued vIBAN, toggled per batch
Statements — the period totalled, every vIBAN downloadable on its own.
/// 04

Statements the finance team opens

The period on screen holds €412,380.44 across 8,912 credits, 99.6% auto-reconciled — with the 34 manual cases and 12 returned payments counted rather than hidden. Every vIBAN exports its own statement as CSV or PDF, the whole period exports in one action, and monthly statements email themselves to the finance inbox on the 1st.

Events & webhooks — the stream on the left, the endpoints on the right.
/// 05

Webhooks with delivery receipts

Every credit, return, issue, and pause is an event, and every event shows its delivery: status code, latency, and retry state per attempt. Deliveries are signed with HMAC-SHA256 and retried 6 times over 24 hours with exponential backoff — and a delivery that exhausts its retries gets a manual retry button, not a shrug.

  • [ 01 ]payment.incoming, payment.returned, viban.* — subscribed per endpoint
  • [ 02 ]Per-endpoint secrets; endpoints pause without being deleted
  • [ 03 ]8,946 events in the last 24 h, 99.7% delivered — printed on the page
The receiving accounts — one active per currency, every change audited.
/// 06

The accounts behind the program

In the operator console, the receiving accounts behind the program are data, not tribal knowledge: one active account per currency, and retiring one promotes the next sibling automatically. Every change asks for a written reason and lands in the audit log.

/// And more

Per-payer IBANs

Every payer gets a dedicated IBAN, so every incoming payment names its sender before anyone looks at it. There is no reference field to mistype and no matching queue to work through. Identification is a property of the account number, not a process.

Purpose tags

Each vIBAN carries a tag: rent-collection, subscriptions, marketplace-payouts, payroll. Flows stay separated at the account level, so reporting by purpose is a filter, not a project.

Reconciliation by construction

When each payer pays into their own IBAN, an incoming credit can only mean one thing. In the demo period, 99.6% of 8,912 credits reconcile themselves — and the handful that cannot land in a manual queue instead of a mystery.

One master account

Behind every vIBAN sits one real account. Funds concentrate automatically — no sub-account balances to sweep, no fragmentation to manage. The surface is thousands of addresses; the ledger is one.

Dedicated IBAN ranges

vIBANs issue from dedicated ranges — the demo program runs under RO49 PRCT, with the free count per range shown at issue time. Ranges keep programs, brands, or entities cleanly separated while everything still routes into the master account.

Per-payer history

Each vIBAN accumulates its own payment history, so a payer's record is complete by definition. A dispute or an audit starts from a filtered list, not an investigation.

Built for platforms

Seller and tenant onboarding can mint a vIBAN as a step in the flow: create the account, hand over the IBAN, start collecting. The customer view ships whitelabel — the demo runs as Powered by Protocore; yours runs under your brand.

Returns, counted

Some payments bounce — an account closed, details wrong. SEPA returns carry their reason code into a payment.returned event and their own count on the statements page — data with a cause attached, not mysteries. The edge case has a row, not a support thread.

Pause without ceremony

A vIBAN pauses in one action, and the event stream records who paused it and from where. Paused reads as a status everywhere the IBAN appears — the book, the statements, the stream.

Drafts before batches

A configured batch saves as a draft: source validated, range picked, nothing issued yet. The flow runs source, configure, review — so the irreversible click is the last one, on purpose.

Allowances you can plan against

Issuing runs against a monthly allowance with the meter in view, and a batch states what it adds before you run it — 1,204 of 5,000 used, this batch makes it 3,604. Capacity is arithmetic, not an error message.

Reference prefixes per batch

Each batch stamps its credits with a reference prefix — ARC-PAYOUT- in the demo — so downstream systems recognize their own flows on sight.

Your ids travel with ours

Every payer row carries an external reference from your system — EXT-00311 in the demo — and it stays attached to the vIBAN. Lookups run on your identifiers, not just ours.

Console and API are twins

Everything the console does, the API does — issue, pause, query, export. The CSV upload and the API call drive the same operation; the console is a client, not a special path.

Test events before real money

Send a test event to any endpoint straight from the console. The integration proves itself against synthetic deliveries before the first real credit arrives.

Endpoints with hygiene

Endpoints carry their own signing secrets and their own subscriptions, and they pause without being deleted — the demo keeps a paused staging endpoint right next to the active production one.

Exports in two shapes

CSV for machines, PDF for people — per vIBAN or for the whole period. The export is designed to be imported, not re-typed.

Statements on a schedule

Monthly statements email themselves to the finance address on the 1st. The routine report is a subscription, not a recurring task on someone's list.

Filter the stream

Events filter by type, vIBAN, or reference; the console book searches by IBAN, customer, or reference. Finding one payment among thousands is a query with three entry points.

Every change with a reason

Operator changes to the program — accounts, pauses, retirements — are reason-required and land in the audit log. The program's history explains itself in writing.

/// In the product
The console — every virtual IBAN, tagged and reconciled.
The payer's view — a dedicated IBAN that is theirs alone.
  • Bulk issue — 2,400 rows validated, IBANs reserved, one action to issue.
  • Statements — €412,380.44 in, 99.6% auto-reconciled, CSV or PDF per vIBAN.
  • Events & webhooks — every credit as a signed delivery, retries in the open.
Behind the program — receiving accounts, exactly one active per currency.
/// FAQ

Virtual IBANs, answered.

  • They're addressable IBANs issued from dedicated ranges that route into one master account. A payment to a vIBAN arrives like any SEPA credit; funds concentrate in the master automatically — no sweeping jobs.

  • The return carries its reason code into a payment.returned event and its own statement count. Returns are data with a cause attached, not mysteries to chase.

  • You need an exception process, not a matching team. One payer per IBAN makes credits self-identifying — 99.6% auto-reconciled in the demo — and the remainder queues for review with full payer history attached.

  • Issue in bulk — a CSV of 2,400 payers validates, previews, and issues in one action — and tag each vIBAN by purpose. Every seller, tenant, or entity gets its own reconcilable account number; reporting by purpose becomes a filter, not a project.

/// Evaluate

Issue a virtual IBAN and watch it reconcile.

[ 01 ]

Guided demo walkthrough

We run the full loop with you — issue, share, match, except, report — on the same demo data, including the 2,400-payer bulk issue.

[ 02 ]

Sandbox tenant

A test program with a master account and issuing enabled, so your team can mint vIBANs, send test credits, and see them self-identify.

[ 03 ]

API access, webhooks, and docs

The issuing API, payment and lifecycle webhooks, and the integration docs — enough to wire reconciliation into your own back office.

[ 04 ]

Standalone or whitelabel

Evaluate under the Protocore brand or issue under yours — the master account stays the single line of truth either way.

Request sandbox access
/// Further reading
Availability

Available standalone or whitelabel — issue under your brand.

In the ecosystem

Gateway's pay-by-transfer orders carry vIBAN references, PoS payouts land on the same IBAN rails, and Center works the exceptions vIBAN's matching leaves behind.

Pick a product. Or take the core.

Everything above runs in production demos we can walk you through — standalone, whitelabel, or as one platform. Tell us what you're building and we'll show you the shortest path to it.

Contact us