--- title: "BIN Sponsorship - No IBAN Model - Partner Guide" slug: "bin-sponsorship-no-iban-model-partner-guide" updated: 2026-07-10T12:19:27Z published: 2026-07-10T12:19:27Z canonical: "www.documentation.paynetics.digital/bin-sponsorship-no-iban-model-partner-guide" --- > ## 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 - Partner Guide # **1. Overview** The No IBAN Model is a lightweight variant of Paynetics' BIN Sponsorship offering, designed for Program Managers whose end customers do not need IBAN accounts. Paynetics sponsors the BIN and License; the Program Manager and its Processor operate the day-to-day card program; reconciliation and Settlement run on a daily file cycle. The model is processor-agnostic — any Processor that meets the requirements in this guide can serve it. The model fits when both answers are "No": *1. Does the offering require IBANs for end customers?* *2. Does the Program Manager require near-real-time visibility from Paynetics?* If either is "Yes", the Classic BIN Sponsorship model is the correct fit. # **2. How the Model Works** ## **2.1 System boundaries and role split** The Program Manager's real-time ledger (operated through its Processor) is the source of truth for authorization, Balance, and live transaction processing. Paynetics' reporting database is updated end-of-day from the daily reporting files and is used for reconciliation, regulatory reporting, scheme settlement, and audit. ![System boundaries](https://cdn.document360.io/4bc02332-492c-444b-85e7-bf524fc0dcb5/Images/Documentation/bin-sponsorship---no-iban-model---partner-guide-image-34rhldeo.png?sv=2026-02-06&spr=https&st=2026-11-15T00%3A30%3A18Z&se=2026-11-15T01%3A30%3A18Z&sr=c&sp=r&sig=L1F5lUjOWfijfEYxThNXASvL6zrW%2FoMvK2HNh530JqE%3D) - **Program Manager:** end-customer experience, real-time ledger, authorization, balance management, fraud monitoring. Acts as Paynetics' agent. - **Processor:** issues cards on the Paynetics BIN, authorizes on the Program Manager's behalf, produces the daily reporting files. - **Paynetics:** BIN and License sponsor; operates Funding and Settlement accounts; settles with the schemes; holds the contractual relationship with the end customer. - **Card Schemes:** settle with Paynetics as the BIN holder on the agreed scheme cycle. ## **2.2** Account **and card setup** The Program Manager creates the customer and a no-IBAN account in Paynetics, then issues the card at its Processor carrying the Paynetics Account Token. Card creation, and every subsequent card lifecycle event (activation, reinstatement, suspension, termination), reaches Paynetics in real time via the Register Card Webhook — the same webhook contract used in the Classic BIN Sponsorship model. ![Account and card creation flow](https://cdn.document360.io/4bc02332-492c-444b-85e7-bf524fc0dcb5/Images/Documentation/bin-sponsorship---no-iban-model---partner-guide-image-4cghutuf.png?sv=2026-02-06&spr=https&st=2026-11-15T00%3A30%3A18Z&se=2026-11-15T01%3A30%3A18Z&sr=c&sp=r&sig=L1F5lUjOWfijfEYxThNXASvL6zrW%2FoMvK2HNh530JqE%3D) ## **2.3 Card transactions** Authorization (balance, limit, fraud, decline logic) sits entirely with the Program Manager and its Processor. Paynetics has no real-time involvement. Cleared transactions reach Paynetics in the next-day clearing file. ![Card transaction flow](https://cdn.document360.io/4bc02332-492c-444b-85e7-bf524fc0dcb5/Images/Documentation/bin-sponsorship---no-iban-model---partner-guide-image-e02fpuo6.png?sv=2026-02-06&spr=https&st=2026-11-15T00%3A30%3A18Z&se=2026-11-15T01%3A30%3A18Z&sr=c&sp=r&sig=L1F5lUjOWfijfEYxThNXASvL6zrW%2FoMvK2HNh530JqE%3D) ## **2.4 Daily settlement** On processing day T, the Program Manager performs a single Funding → Settlement transfer, per settlement currency, equal to the settlement amount owed to the card schemes for day T. The transfer is completed before the scheme settlement cut-off for day T. Paynetics reconciles the transfer against the scheme-cleared total once the reporting files have been received, then settles with the schemes on the established net-basis cycle. ![Daily settlement flow](https://cdn.document360.io/4bc02332-492c-444b-85e7-bf524fc0dcb5/Images/Documentation/bin-sponsorship---no-iban-model---partner-guide-image-ti0t6ry4.png?sv=2026-02-06&spr=https&st=2026-11-15T00%3A30%3A18Z&se=2026-11-15T01%3A30%3A18Z&sr=c&sp=r&sig=L1F5lUjOWfijfEYxThNXASvL6zrW%2FoMvK2HNh530JqE%3D) - The Processor delivers reporting files by the Paynetics-set cut-off (at least 2 hours before the scheme settlement cut-off). - The Program Manager is contractually obliged to keep the Funding Account topped up and to perform the daily transfer at the correct amount; any mismatch is flagged by Paynetics at reconciliation and the Program Manager corrects. ## **2.5 Reconciliation** Paynetics reconciles the Program Manager's daily Funding → Settlement transfer against the scheme-cleared total. Mismatches and missing data are flagged within T+1. Late files trigger an operational alert; scheme settlement proceeds regardless. If the Settlement balance is short, the collateral held there acts as the immediate buffer and the Program Manager corrects the position. ![Reconciliation flow](https://cdn.document360.io/4bc02332-492c-444b-85e7-bf524fc0dcb5/Images/Documentation/bin-sponsorship---no-iban-model---partner-guide-image-y6gd9i8o.png?sv=2026-02-06&spr=https&st=2026-11-15T00%3A30%3A18Z&se=2026-11-15T01%3A30%3A18Z&sr=c&sp=r&sig=L1F5lUjOWfijfEYxThNXASvL6zrW%2FoMvK2HNh530JqE%3D) ## **2.6 Card termination** Cards are terminated by the Program Manager or its Processor at any time. Termination reaches Paynetics in real time via the Register Card webhook (state.terminated), under the same webhook contract used for all card lifecycle events. Paynetics marks the card ineligible for further authorization, clearing, and settlement. Card records are retained for at least 5 years. ![Card termination flow](https://cdn.document360.io/4bc02332-492c-444b-85e7-bf524fc0dcb5/Images/Documentation/bin-sponsorship---no-iban-model---partner-guide-image-icz9e1yx.png?sv=2026-02-06&spr=https&st=2026-11-15T00%3A30%3A18Z&se=2026-11-15T01%3A30%3A18Z&sr=c&sp=r&sig=L1F5lUjOWfijfEYxThNXASvL6zrW%2FoMvK2HNh530JqE%3D) # **3. What we need from the Processor** Onboarding requires full coverage of the Mandatory requirements below. Optional capabilities improve operational quality but are not gating. ## **3.1 Mandatory (PR-M)** | **ID** | **Requirement** | | --- | --- | | PR-M-01 | Issue cards on the Paynetics-sponsored BIN and embed/return a Paynetics account token for every card created. | | PR-M-02 | Deliver the daily reporting files as specified by the Paynetics Finance, Chargeback and Monitoring teams. File list, contents, fields, and cadence are confirmed per Processor during integration. | | PR-M-03 | Operate real-time fraud and AML transaction monitoring; certify the monitoring framework to Paynetics annually. The monitoring may be run by the Program Manager or by the Processor. | | PR-M-04 | Provide an audit trail sufficient for regulatory and scheme audits that allows reconstruction of any transaction's lifecycle on demand. | | PR-M-05 | Be certified by the relevant Card Scheme(s) and deliver scheme clearing files (T140, MC advisement, VSS) directly to Paynetics. | | PR-M-06 | Identify chargebacks within the daily clearing file with reason codes per scheme rules; signal chargeback events in the format agreed with the Paynetics Chargeback team during integration. | | PR-M-07 | Provide a documented business-continuity / disaster-recovery plan for file delivery and authorization; share operational escalation contacts and an incident notification channel with Paynetics. | | PR-M-08 | Notify Paynetics within 1 hour of detecting any incident affecting authorization, file delivery, or scheme processing; provide an initial response within 2 hours of notification; respond to routine operational queries within 1 business day. Severity-based resolution windows are agreed with Paynetics Card Operations at integration. | | PR-M-09 | Send a Register Card webhook to Paynetics in real time for every card lifecycle event — fulfillment.issued, state.activated, state.reinstated, state.suspended, state.terminated. Webhook contract and payload follow the existing implementation used in the Classic BIN Sponsorship model. Each event must carry the Paynetics account token via card metadata. | ## **3.2 Optional (PR-O)** | **ID** | **Capability** | | --- | --- | | PR-O-01 | Intra-day report deliveries (multiple cuts per day). | | PR-O-02 | Sandbox or test environment accessible to Paynetics during integration. | | PR-O-03 | API or portal access for Paynetics support to look up individual transactions on demand (read-only). | | PR-O-04 | Paynetics access to the Processor's system to block or terminate cards on demand. | # **4. Reporting** The reporting framework captures the most important fields per file rather than an exhaustive per-field spec; each Processor's native format is accepted and matched at integration. The current working set: | **Report** | **Purpose for Paynetics** | | --- | --- | | Authorizations | Reconciliation; fraud and compliance oversight. | | Presentment, Interchange & Fees (clearing file) | Clearing reconciliation; chargeback identification; FX. | | Account Balance / Account Status | Aggregate balance and account lifecycle reconciliation. | | Network Fees | Commercial reporting. | | Ledger Entries | End-to-end audit reconstruction. | | Scheme settlement (T140, MC advisement, VSS) | Scheme-facing settlement on Paynetics' side. | | Balance Report — baseline | Both PAD and PUK programs operating non-zero end-customer balances. Daily snapshot referenced to 00:00 UTC. | | Balance Report — UK Safeguarding (additional) | PUK programs operating non-zero balances. Referenced to 13:00 UTC; delivered no later than 14:00 UTC. | **Delivery timing.** Balance Reports are snapshot-based and delivered on processing day T — the baseline at 00:00 UTC for both PAD and PUK, and the additional UK Safeguarding report at 13:00 UTC, delivered no later than 14:00 UTC the same day. All other files capture activity during day T and are delivered on day T+1, per the general Paynetics-set cut-off (no later than 2 hours before the scheme settlement cut-off). Chargebacks are identified within the daily clearing file and joined to the Paynetics account via the card-to-account mapping (PR-M-01). The detailed chargeback handling process is documented in the Issuing Dispute Procedure for Program Managers, available separately from Paynetics. # **5. Safeguarding, Compliance and Collateral** - **Safeguarding:** end-customer funds in scope of safeguarding are held in segregated accounts at PUK or PAD per the applicable EMI regulator. Programs operating non-zero balances are covered by the daily Balance Report cadence in Section 4. - **Collateral:** mandatory, held in the Settlement account, governed by Paynetics Finance. Default guideline: 4× Average Daily Transaction Volume per Program Manager. Sizing and review are negotiable. - KYC **and AML:** the Program Manager acts as Paynetics' agent. End customers are Paynetics' customers contractually and regulatorily. KYC may be Program-Manager-managed (subject to Paynetics' compliance standards) or Paynetics-managed. Annual certification of real-time monitoring is required (PR-M-03). - **Three-party agreement:** the Paynetics / Program Manager / Processor agreement anchors reporting, settlement, fraud monitoring, change-control on file schemas, and audit obligations. - **Card record retention:** at least 5 years. # **6. Service Levels and Operational Targets** | **Area** | **Target** | | --- | --- | | Technical integration | ≤ 8 weeks from kick-off to integration complete | | Daily file delivery on time | ≥ 99% on T+1 | | Clearing match rate | 100% within reconciliation SLA | | Reconciliation exception resolution | T+1 business day from flag | | Collateral coverage | ≥ the agreed collateral amount | | Chargeback data completeness | 100% of required fields per disputed transaction | # **7. Glossary** | **Term** | **Meaning** | | --- | --- | | ADTV | Average Daily Transaction Volume (basis for the collateral guideline). | | BIN | Bank Identification Number. | | Classic model | The full BIN Sponsorship model with IBAN issuance and near-real-time visibility. | | PAD / PUK | Paynetics AD / Paynetics UK — the two Paynetics entities that can host a program. | | PIF / Clearing file | Presentment, Interchange & Fees — the Processor's daily clearing file. | | PR-M / PR-O | Processor Requirement, Mandatory / Optional. | | Program Manager | The Partner operating the end-customer experience, real-time ledger, and day-to-day card program. | | Processor | The third-party card processor selected by the Program Manager. | | Three-party agreement | Commercial agreement between Paynetics, the Program Manager, and the Processor. | | T+1 | The business day following processing day T. | | T140 / MC advisement / VSS | Mastercard / Visa scheme settlement reports. | 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. 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 actual transfer of funds between financial institutions to complete a card transaction or a batch of transactions. In the BIN Sponsorship context, settlement refers to the daily funding movement from the Programme Manager to Paynetics to cover net scheme obligations. A **Balance** represents an amount of funds held in a specific currency within an account. An account may have multiple balances, typically one per supported currency. Balances are assigned payment identifiers such as IBANs or account numbers, depending on the currency. All monetary operations reference a **balance token**, which is used in API calls to debit or credit funds, perform transfers, or apply fees. 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 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. 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 type used to hold and distribute funds for programme operations. Funding accounts serve as the money pool from which programme activity is financed. 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 network that processes and settles card transactions between issuers and acquirers. Paynetics partners with Visa and Mastercard. Card schemes set the rules governing interchange, chargebacks, authorisation, and scheme participation. Paynetics' isolated test environment that mirrors the production platform. Partners use the sandbox during the Technical Integration Phase to build, test, and validate their integration before going live. The sandbox supports the full API surface including card issuance, transactions, and webhooks. 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 business of issuing payment cards to consumers. An issuer approves or declines card transactions in real time and is liable for cardholder credit risk. Paynetics acts as issuer for its partners' card programmes. 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. 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. A **Partner** is the entity that integrates Paynetics’ services and offers them to end customers. Partners operate within their own instance and manage users, merchants, applications, and programs. They define fees, user flows, and configurations within the limits of their contractual agreement and may be responsible for KYC or KYB processing. The partner is the primary integrator and owner of the end-to-end solution built on Paynetics.