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.

• 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.

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.

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.

• 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.

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.

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)

3.2 Optional (PR-O)

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:

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

7. Glossary