Visa and Mastercard Network and Scheme Rules
|
|
| Regulator |
Visa / Mastercard |
| Jurisdiction |
Global |
| Status |
live |
| Applicability |
Platform |
Visa and Mastercard operating regulations are binding contractual obligations for all scheme members
— they are not government regulations but carry the force of contract, backed by financial penalties
and scheme membership revocation for non-compliance. The bank operates as a card issuer and acquirer
under both schemes. Compliance is mandatory as a condition of the membership agreement signed with
each scheme. PCI DSS compliance is required by both schemes (see PCI DSS v4.0).
Key obligation areas include: issuer rules (credit limits, authorisation, fraud programme, chargeback
liability), acquirer rules (POS compliance, settlement, merchant agreement), dispute and chargeback
resolution (8-day presentment, 45-day arbitration deadlines), fraud reporting thresholds (Visa GFRS /
Mastercard SAFE), 3DS2 authentication requirements, and network processing standards. Both schemes
update their operating regulations on a bi-annual publication cycle; the compliance programme must
track scheme bulletins and implement required changes before the effective date.
Compliance register
This register maps every material obligation under the Visa and Mastercard scheme rules to the
platform control or institutional process that satisfies it. It is the static traceability layer
for the Totara compliance report — dynamic data (module build status, test evidence, control test
dates) is overlaid at runtime.
Scope legend
| Symbol |
Meaning |
| 🤖 Automated |
Platform enforces or performs the obligation. Primary control mode is GATE, AUTO, CALC, or ALERT. Human action is not required in the normal case. |
| 📊 Evidenced |
Platform captures the evidence trail automatically. Human compliance decision sits on top. Primary control mode is LOG. |
| 🏛 Institutional |
Obligation is met by a process entirely outside the platform — scheme registration, programme management, legal. Platform may generate evidence inputs but does not own the process. |
| N/A |
Obligation does not apply to this deployment configuration. |
Build legend
| Symbol |
Meaning |
| ✅ |
Module built and deployed |
| 🔨 |
Module planned — not yet built (build_status: Not started) |
| ❌ |
Uncontrolled gap — no module attributed |
Issuer obligations
| Ref |
Obligation |
Scope |
Policy |
Platform controls |
Build |
| Issuer — Card production |
Physical cards produced and personalised to scheme specifications before bureau submission; PIN management via HSM |
🤖 Automated |
PAY-003 |
MOD-124 (GATE) — card personalisation file conforms to Visa/Mastercard scheme specifications before submission to the bureau; only issued after passing scheme compliance checks |
🔨 |
| Issuer — P2PE |
Card personalisation data transmitted to bureau using point-to-point encryption; full PANs never stored in application logs outside PCI DSS-compliant storage |
🤖 Automated |
PAY-003 |
MOD-124 (AUTO) — card personalisation data transmitted with P2PE; full PANs not in application databases outside PCI scope |
🔨 |
| Issuer — PIN management |
PIN set and PIN change operations via HSM-backed PIN management; PINs never in plaintext at any point |
🤖 Automated |
PAY-003 |
MOD-124 (GATE) — PIN set and PIN change operations use the bank's HSM-backed PIN management service; PINs never in plaintext in the processing chain |
🔨 |
| Issuer — Lost/stolen card |
Card replacement initiated automatically when a card is reported lost or stolen; no manual intervention required to trigger the replacement order |
🤖 Automated |
PAY-003 |
MOD-124 (AUTO) — card replacement is initiated automatically on lost/stolen report |
🔨 |
| Issuer — Fraud reporting |
Report fraud events to Visa GFRS / Mastercard SAFE at or above scheme threshold; maintain fraud rate below scheme maximums |
📊 Evidenced |
PAY-003 |
MOD-022 (LOG) — scheme compliance evidence: every card transaction has full processing record; fraud event logging provides the data foundation for scheme fraud reporting |
🔨 |
| Issuer — 3DS2 |
Strong customer authentication (3DS2) required for e-commerce card-not-present transactions |
🤖 Automated |
PAY-003 |
MOD-124 (GATE) — card scheme compliance checks gate; 3DS2 authentication integrated in card-not-present flow |
🔨 |
Acquirer and processing obligations
| Ref |
Obligation |
Scope |
Policy |
Platform controls |
Build |
| Acquirer — Settlement |
Settlement and clearing completed on scheme timelines; settlement reconciliation errors resolved within required window |
📊 Evidenced |
PAY-003 |
MOD-022 (LOG) — every card transaction has full processing record; settlement dispute resolution uses the immutable payment audit trail |
🔨 |
| Acquirer — CoP |
Payee name verified against destination account before customer confirms outbound payment; CoP result and customer acknowledgement recorded with payment record for fraud liability |
🤖 Automated |
PAY-003 |
MOD-144 (AUTO) — CoP result and customer acknowledgement recorded with payment record for fraud liability and audit purposes |
🔨 |
Dispute and chargeback resolution
| Ref |
Obligation |
Scope |
Policy |
Platform controls |
Build |
| Chargeback — Presentment |
Respond to chargeback presentments within 8-day scheme deadline; provide compelling evidence where applicable |
📊 Evidenced |
PAY-003 |
MOD-022 (LOG) — immutable payment audit trail provides evidence base for chargeback representment; every card transaction has full processing record |
🔨 |
| Chargeback — Arbitration |
Submit arbitration cases within 45-day scheme deadline; maintain documentation |
🏛 Institutional |
PAY-003 |
MOD-022 provides the payment evidence record; dispute management is an institutional process with scheme-defined timelines |
— |
| Chargeback — Escalation |
Track and surface scheme obligations for dispute resolution across transactions |
🤖 Automated |
PAY-003 |
MOD-144 (AUTO) — CoP result and acknowledgement are recorded with the payment record; dispute tracking is surfaced through the payment audit trail |
🔨 |
PCI DSS mandate
| Obligation |
Scope |
Policy |
Platform controls |
Build |
| PCI DSS compliance as a condition of scheme membership |
🤖 Automated |
PAY-003, PAY-006 |
MOD-124 (AUTO, GATE) — P2PE and HSM-based controls; MOD-046 (GATE) — no standing production access; MOD-045 (AUTO) — key management; MOD-044 (GATE) — RBAC |
🔨 |
See PCI DSS v4.0 for the full PCI DSS obligation register.
| Obligation |
Owner |
Platform evidence input |
| Scheme membership registration and principal membership applications (Visa / Mastercard) |
Head of Payments |
Institutional legal and compliance process |
| Tracking scheme bulletins and certifying changes before effective date |
Head of Payments |
Institutional compliance programme |
| Annual QSA PCI DSS audit or SAQ completion |
CISO / Head of Payments |
MOD-044, MOD-045, MOD-046 provide control evidence |
| Negotiating scheme agreement terms and processing contracts |
Head of Payments / Legal |
Not platform scope |
| Staff training on scheme rule updates |
Head of Payments |
Institutional training programme |
Coverage summary
| Area |
Total obligations |
Platform automated 🤖 |
Platform evidenced 📊 |
Institutional 🏛 |
N/A |
| Issuer obligations |
6 |
4 |
2 |
0 |
0 |
| Acquirer / processing |
2 |
1 |
1 |
0 |
0 |
| Dispute / chargeback |
3 |
1 |
1 |
1 |
0 |
| PCI DSS mandate |
1 |
1 |
0 |
0 |
0 |
| Total |
12 |
7 (58%) |
4 (33%) |
1 (9%) |
0 |
All attributed modules are currently build_status: Not started — the compliance position will
update as modules are built and deployed.
| Policy |
Title |
| PAY-003 |
Card Scheme Compliance Policy |
| PAY-006 |
PCI DSS Compliance Policy |
See D06 Payments & Settlement for the full risk domain.
Official documentation
Policies referencing this standard
- PAY-003 — Card Scheme Compliance Policy
- PAY-008 — Payment Routing, Sponsor & Card-Scheme Abstraction Policy
Compiled 2026-05-22 from source/entities/regulations/industry-card-scheme-rules.yaml