The IBAN model is the full-featured Paynetics BIN Sponsorship configuration. It is the right fit for programmes that need end-customer IBAN accounts, near-real-time visibility into card activity on the Paynetics side, or both. Under the IBAN model, the Programme Manager runs the cardholder ledger and authorisation, while Paynetics holds payment accounts for each end customer, processes events in real time as they happen, and settles with the schemes.
For the cross-cutting introduction to BIN Sponsorship as a product — what it is, who Paynetics is as a BIN Sponsor, scheme and jurisdiction coverage — see the BIN Sponsorship Overview article. For the lighter-weight alternative without end-customer IBANs, see BIN Sponsorship — No-IBAN Model.
What is the IBAN BIN Sponsorship model?
The IBAN model is the full-featured BIN Sponsorship configuration. The Programme Manager retains operational control of its card programme — its own cardholder ledger, its own real-time authorisation, its own fraud and risk decisioning, its own customer experience. Paynetics provides the regulated foundation underneath: the BIN, payment accounts on its books for every end customer (each with its own IBAN where applicable), real-time event ingestion through webhooks, scheme-facing clearing and settlement, and the e-money licence and regulatory umbrella the programme operates under.
Because end customers hold payment accounts with IBANs on the Paynetics side, the programme can support inbound transfers from external accounts — salary, refunds, account-to-account top-ups — and the accounts are addressable in SEPA. Because Paynetics receives events in real time, the Paynetics side carries a live record of activity that matches what the Programme Manager sees on its own ledger.
What Paynetics provides
A dedicated BIN (or BIN range) under Visa and Mastercard
A payment account on Paynetics' books for every end customer, with an IBAN where the regulatory and product configuration supports it
Real-time event ingestion: a webhook channel that accepts transaction, authorisation, fee and lifecycle events from the Programme Manager's processor
Funding, System and Settlement accounts on the Paynetics side, and the Transfers API the Programme Manager uses to move money between them
A shadow ledger maintained by Paynetics for compliance, audit, regulatory reporting and reconciliation
Daily scheme settlement with Visa and Mastercard, on Paynetics' established scheme-settlement cycle
The regulatory umbrella (EMI licence via Paynetics AD in the EEA, Paynetics UK in the UK) and the chargeback and dispute interface with the schemes
What the Programme Manager controls
The real-time cardholder ledger and balance management
Real-time authorisation decisions (approve, decline, balance and limit checks)
Fraud monitoring, risk decisioning and AML transaction monitoring
The cardholder-facing experience: app, customer support, communications
The choice of card processor — either a processor Paynetics has already integrated with, or one the Programme Manager brings (subject to Paynetics' processor requirements and approval)
Programme design — card products, spending rules, fee structure, end-customer journey
Visibility and reporting
Under the IBAN model, Paynetics has near-real-time visibility into card activity. The Programme Manager's processor sends a webhook to Paynetics for every transaction event — authorisation, authorisation reversal, clearing, fee — as it occurs. The webhook is informational on the Paynetics side: it doesn't move money, but it does keep the Paynetics shadow ledger and the Programme Manager's ledger in sync as activity happens.
Daily reconciliation files supplement the live webhook channel — they provide the authoritative scheme-cleared totals against which the day's webhook events and Transfers API calls are reconciled.
Settlement and reconciliation
Each day, Paynetics receives the scheme clearing files (Visa VSS, Mastercard advisement and T140) directly from the Programme Manager's processor. The Programme Manager initiates a Transfers API call to move the scheme-cleared total from its System account to the Paynetics Settlement account. Paynetics settles the matched amount with the schemes on the established scheme-settlement cycle.
Discrepancies between webhook events and the daily reconciliation files are flagged for the Programme Manager to resolve within T+1 business day. A collateral buffer is held in the Settlement account, sized in agreement with Paynetics Finance, to cover short-term scheme-settlement risk during the resolution window.
Card lifecycle
Card lifecycle events under the IBAN model — issuance, activation, suspension, reinstatement, termination — reach Paynetics in real time through the Register Card webhook. Each event carries the Paynetics account token so the card record on Paynetics' side is bound to the correct account at the moment the event occurs. The webhook contract is consistent with Paynetics' established implementation used across processor integrations.
Compliance and safeguarding posture
The Programme Manager operates as Paynetics' agent. End customers are Paynetics' customers contractually and regulatorily; Paynetics retains regulatory responsibility for KYC and AML, which can be delegated operationally to the Programme Manager under Paynetics' compliance standards. End-customer funds in scope of safeguarding are held in segregated accounts at Paynetics UK or Paynetics AD, per the applicable EMI regulator. Because the Paynetics side carries the end-customer balance in real time, safeguarding tracks the live per-customer position.
The Programme Manager runs real-time fraud and AML transaction monitoring and certifies the monitoring framework to Paynetics annually. Reporting on monitoring activity, risk exposure, transaction and portfolio performance, and chargebacks is delivered to Paynetics on cadences agreed at integration.
Best fit for
Programmes that need end-customer IBAN accounts — for example, neo-bank products where the cardholder is also receiving inbound transfers, or business-account products where the IBAN is the identifier of record. Programmes that need near-real-time visibility from Paynetics, whether for regulatory reporting reasons, operational risk reasons, or because the end-customer experience depends on it. Mature Programme Managers with an established processor, a real-time ledger and the operational maturity to run transaction-level integration with Paynetics' Transfers API.
Choosing between IBAN and No-IBAN
Dimension | IBAN | No-IBAN |
|---|---|---|
End-customer IBANs | Yes — each end customer holds an IBAN-bearing payment account on the Paynetics side | No — end customers do not hold IBANs |
Real-time visibility on the Paynetics side | Yes — live webhooks for every transaction, fee and lifecycle event | End-of-day visibility through daily reporting files (card lifecycle events still real-time via webhook) |
Integration weight | Heavier — Transfers API integration, live webhook ingestion, per-transaction reconciliation | Lighter — daily file ingestion, no per-transaction movement |
Collateral | Held in the Settlement account, sized in agreement with Paynetics Finance | Held in the Settlement account, sized in agreement with Paynetics Finance |
Best fit | Programmes that need IBANs or near-real-time visibility from Paynetics | Programmes that don't need either |
The choice is a commercial decision per Programme Manager. The model is processor-agnostic — any processor that meets Paynetics' processor requirements can serve either model.