The No-IBAN model is the lighter-weight Paynetics BIN Sponsorship configuration. It is the right fit for programmes whose end customers don't need IBAN-bearing accounts and whose operations don't require near-real-time visibility from Paynetics. It runs on the same sponsorship structure as the IBAN Model — Paynetics holds the BIN and the regulatory umbrella; the Programme Manager runs the ledger, Authorisation and fraud — but with a simpler money flow, daily-file reporting in place of live webhooks for transactions, and a single daily settlement movement instead of per-transaction transfers.
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 programmes that need end-customer IBANs or real-time visibility, see BIN Sponsorship — IBAN Model.
What is the No-IBAN BIN Sponsorship model?
The No-IBAN model is a streamlined variant of BIN Sponsorship designed for faster, lower-cost integration. Paynetics still sponsors the BIN, holds the E-Money licence, settles with the schemes and maintains a shadow ledger for compliance. The Programme Manager still runs the Cardholder ledger, authorisation, fraud monitoring and the cardholder-facing experience. What changes is the shape of the integration between the two sides.
End customers don't hold IBAN-bearing accounts on the Paynetics side. Cards under the model can be zero-balance — funded just-in-time from the Programme Manager's Funding account at the moment of each transaction, with no per-customer balance held by Paynetics — or they can carry stored value, in which case the Programme Manager's daily reporting tells Paynetics the per-customer position. Card lifecycle events (issuance, activation, suspension, reinstatement, termination) reach Paynetics in real time through the Register Card Webhook; cleared transactions, fees and scheme settlement reach Paynetics end-of-day through daily reporting files.
What Paynetics provides
A dedicated BIN (or BIN range) under Visa and Mastercard
A regulated Account record on Paynetics' side for each end customer, created without an IBAN
A daily file-based reporting ingestion pipeline that consumes the Programme Manager's reporting set (authorisations, Clearing, fees, account balance, scheme settlement and supporting files)
Real-time card lifecycle event ingestion through the Register Card webhook
Funding and Settlement accounts on the Paynetics side, with a daily Funding → Settlement transfer initiated by the Programme Manager
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
Delivery of the daily reporting files from the Programme Manager's processor to Paynetics, on the agreed cadence and cut-off
Initiating the daily Funding → Settlement transfer at the correct amount, before the scheme-settlement cut-off
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)
Visibility and reporting
Under the No-IBAN model, Paynetics is updated end-of-day from the Programme Manager's processor through a defined set of daily reporting files. The files cover authorisations, clearing (Presentment, Interchange & Fees), account balance and account status, network fees, ledger entries, and scheme settlement (T140, Visa VSS, Mastercard advisement). Paynetics' compliance and regulatory record is built from these files, end-of-day.
Card lifecycle events are the exception: they reach Paynetics in real time via the Register Card webhook, the same webhook contract used in the IBAN model. This keeps Paynetics' card record on the Paynetics side bound to the correct account at the moment of issuance and updated as the card's state changes.
The reporting file set is owned by Paynetics' Finance, Chargeback and Monitoring teams. The exact field set on each file is matched against the Programme Manager's processor reports at integration; supplementary files or columns are agreed where the processor's native reports don't cover a needed data point.
Settlement and reconciliation
Once per processing day, the Programme Manager initiates a single Funding → Settlement transfer equal to the settlement amount owed to the card schemes for the day. The transfer is completed before the scheme-settlement cut-off. The Programme Manager's processor delivers the daily reporting files to Paynetics by a Paynetics-set cut-off (at least two hours before the scheme-settlement cut-off). Paynetics ingests the files, reconciles the Programme Manager's transfer against the scheme-cleared total derived from the clearing files, and alerts the Programme Manager if the amounts don't match.
Because Paynetics works a day behind on transaction data, a collateral buffer is held in the Settlement account to cover the financial exposure during the daily-lag window. The exact amount is agreed with Paynetics Finance and reviewed periodically.
Mismatches and missing data are flagged within T+1 and resolved by the Programme Manager within one business day of the flag. The scheme settlement cycle continues regardless — any reconciliation gaps are settled after the fact.
Card lifecycle
Card lifecycle events under the No-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, the same contract used in the IBAN model.
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. The way the safeguarding pool is structured depends on the variant of the No-IBAN model:
Zero-balance programmes — there is no per-customer balance to safeguard at customer level; the safeguarded pool sits at the Funding account level.
Programmes carrying stored value — the Programme Manager's processor delivers a daily Balance Report that gives Paynetics the per-customer position, and the safeguarded amount tracks that position. UK programmes operating non-zero end-customer balances receive an additional daily Balance Report timed to support UK Safeguarding compliance.
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 whose end customers don't need IBAN-bearing accounts — spending-card products, gift-card or pre-loaded benefit-card products, programmes where the card is the primary value proposition and account-to-account inbound transfers aren't part of the offer. Programmes that don't require near-real-time visibility from Paynetics — operationally, the Programme Manager runs the live side and Paynetics' role is end-of-day reconciliation and scheme-facing settlement. New programmes prioritising integration speed and operational simplicity — the No-IBAN model is faster to onboard and lower-cost to operate than the IBAN model, and the controls around it (daily files, collateral and the Paynetics shadow ledger) are sufficient for safeguarding and reconciliation in the populations of programmes it fits.
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.