--- title: "BIN Sponsorship — No-IBAN Model" slug: "bin-sponsorship-no-iban-model" updated: 2026-07-10T12:06:23Z published: 2026-07-10T12:06:40Z canonical: "www.documentation.paynetics.digital/bin-sponsorship-no-iban-model" --- > ## Documentation Index > Fetch the complete documentation index at: https://www.documentation.paynetics.digital/llms.txt > Use this file to discover all available pages before exploring further. # BIN Sponsorship — No-IBAN Model 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. An arrangement in which Paynetics, as a Principal Member of a card scheme, extends its BIN to a Programme Manager's card programmes. The Programme Manager runs the cardholder ledger and authorisation logic; Paynetics holds the regulatory and scheme relationship. International Bank Account Number. A standardised international format for identifying a bank account. In the Paynetics platform, IBANs are assigned at the Balance level, allowing accounts with multiple balances to have separate IBANs per currency. The full-featured Paynetics BIN Sponsorship configuration. Paynetics holds a payment account with an IBAN for each end customer, provides near-real-time event visibility via webhooks, and settles with the schemes per transaction. Suited to programmes requiring end-customer IBAN accounts or real-time Paynetics-side reporting. Bank Identification Number. The first 6 to 8 digits of a payment card number that identify the issuing institution and card scheme. The BIN determines the card network, issuer, and card type for routing and authorisation purposes. The partner entity that, under a BIN Sponsorship arrangement, runs the cardholder ledger, controls authorisation logic, manages the end-customer relationship, and is responsible for fraud monitoring and AML obligations for its programme. The real-time step in a card transaction in which the issuer approves or declines a payment based on available funds, velocity limits, fraud rules, and card status. A successful authorisation places a hold on the cardholder's balance. A Principal Member of a card scheme that makes its BIN available to third-party Programme Managers. Paynetics acts as the BIN Sponsor in BIN Sponsorship arrangements. Electronic Money. Electronically stored monetary value issued against the receipt of funds and redeemable as a means of payment. Paynetics issues e-money as a licensed Electronic Money Institution (EMI) under both UK (FCA) and EU (BNB) regulatory frameworks. The person to whom a Card is issued. The cardholder is responsible for all transactions made with the card in accordance with agreed terms. A **Card** is a payment instrument linked to an account or a virtual account. Cards can be issued as virtual or physical and can be configured for consumer or business use. Each card is associated with a single account and uses the balance of that account for transactions. Card behaviour, including limits, fees, usage permissions, and wallet enablement, is defined by the program and card-level configuration. An HTTP callback that delivers real-time event notifications from Paynetics to a partner's system. Paynetics sends webhook payloads when key events occur—such as a card authorisation, a balance update, or a 3DS challenge—so partners can react immediately without polling the API. An **Account** is a payment or e-money account used to hold funds and execute transactions. Accounts are created under a specific instance and program and are associated with either a user or a merchant. They provide the logical structure under which balances, cards, and transactions are organised. Common account purposes include: - executing card payments and transfers - holding settlement funds - pre-funding services such as OCT An account acts as a container for balances rather than holding funds directly. The post-authorisation step in which transaction records are reconciled and exchanged between the acquirer and the issuing bank through the card scheme. Clearing precedes settlement. Electronic Money Institution. A company authorised to issue electronic money and provide payment services. EMIs are supervised by a national competent authority—for example, the FCA in the UK or the BNB in Bulgaria. Paynetics AD and Paynetics UK Ltd are both EMIs. A transaction reversal initiated by the cardholder's bank on the cardholder's behalf, typically in response to a disputed transaction. The acquiring bank is required to return funds to the issuer, and the merchant may bear the loss depending on the dispute outcome. Anti-Money Laundering. A set of laws, regulations, and procedures designed to detect and prevent criminals from disguising illegally obtained funds as legitimate income. Financial institutions must maintain AML programmes including transaction monitoring, suspicious-activity reporting, and sanctions screening. The fee paid by the acquiring bank to the issuing bank on each card transaction. Interchange rates are set by the card schemes and vary by card type, transaction type, Merchant Category Code (MCC), and geography. Interchange is a key component of card economics for programme managers and partners. The unique internal identifier for an Account, used in all API operations. Separate from any external identifiers such as IBANs, which are assigned at the Balance level, not the Account level. The regulatory requirement for Electronic Money Institutions (EMIs) to protect customer funds by holding them in a dedicated, segregated account separate from company funds. Safeguarded funds are ring-fenced and protected in the event of insolvency. Know Your Customer. The regulatory and risk-management process of verifying the identity of individual customers before onboarding them to a financial service. KYC obligations fall on the entity holding the customer relationship. The standard, most commonly used Account type in the Paynetics platform. Payment accounts provide full current-account functionality: inbound and outbound transfers, card issuance and linking, internal transfers, and one or more Balances depending on Programme configuration.