Module 9: Compliance, PCI-DSS, and Scheme Requirements

"Build trust before you need to prove it."

Objective

This module equips engineering, compliance, product, and executive teams with a clear understanding of:

What compliance frameworks (like PCI-DSS) apply to virtual card systems

How Visa, Mastercard, and other scheme rules affect what you build

How to stay ahead of audits, regulator queries, and partner evaluations

What technical and process controls must be in place to be compliant and audit-ready

Understanding PCI-DSS for Virtual Cards

PCI-DSS (Payment Card Industry Data Security Standard) is the global benchmark for how cardholder data is stored, processed, and transmitted.

While your system may not be storing full PAN/CVV (as cards are issued via a licensed third party), you may still:

Display partial card data

Transmit data during card creation, top-up, or spend

Log metadata (e.g. last 4 digits, BIN, MCC)

Proxy card information through your frontend or backend

Your PCI Responsibilities (as a card distributor or integrator):

AreaMinimum Required
PAN handlingNever store or transmit full PAN/CVV unencrypted
LoggingNo PAN/CVV in logs or plaintext
TransportEnforce HTTPS with TLS 1.2+
Access ControlRole-based controls and encryption at rest
Key ManagementRotate secrets and API keys frequently
System MonitoringAudit access to card-related APIs and UIs
Staff TrainingAnnual PCI awareness training for devs and support

Card Scheme Rules (Visa, Mastercard, etc.)

Your issuing partner is bound by Visa and Mastercard scheme rules, and so are you indirectly.

Key Expectations:

AreaRule
BIN UsageBIN must align with use case — prepaid, debit, consumer/corporate
MCC BlockingCertain MCCs (6051, 7995, 4829) require explicit control
Refund HandlingRefunds must not be routed in a way that creates AML risk
Chargeback HandlingMust respond to disputes within scheme SLA (typically 30 days)
Cross-Border TransactionsMust inform users of FX and apply correct markup
Sanctions & JurisdictionCannot issue to or support users from embargoed countries
Scheme ReportingVolume, dispute rate, chargeback ratios must be monitored and reported

If your platform enables top-up → spend → withdraw, it may fall under stored value or e-money compliance zones, which triggers additional local obligations (e.g., in the EU, UK, or Nigeria).

Examples of Compliance Failures

CaseWhat HappenedConsequence
Stored PAN in logsDev environment captured PAN in console outputPCI breach, potential fine
Unauthorized MCC useEnabled card for MCC 6051 (crypto) without KYC enforcementScheme compliance violation
Delayed chargeback responseFailed to respond in 30-day SLAMerchant debited, issuer penalized
Refund to terminated cardIssued refund to float, no audit trailTreasury exposure, audit gap

Regulatory Zones That May Apply

Even if you're not directly licensed, your platform must design for:

JurisdictionRisk
USStored value, prepaid compliance (FinCEN)
EUPSD2 and e-money directive (for float handling)
NigeriaCBN e-wallet and card issuance circulars
UKFCA oversight for distribution models
IndiaRBI rules for prepaid instruments

You are a regulated surface, even if not a licensed entity. Design like you're regulated.

Partner Due Diligence Readiness

Issuers, banks, and card processors may request due diligence and audit responses. You must be able to demonstrate:

Secure card issuance processes

KYC enforcement prior to high-risk MCCs

Card freeze/terminate workflows

Refund reconciliation across wallet/float/card

Transparent ledger tracking and transaction matching

Chargeback handling playbooks

Developer & Product Responsibilities

RoleResponsibilities
EngineersNever log or store PAN/CVV; verify TLS; sign webhooks; monitor access logs
Product ManagersVerify MCC restrictions, spend limits, refund policies, user flow limits
Compliance OfficersMaintain risk registry; monitor chargeback and refund logs
TreasuryEnsure float reconciliation and partner compliance with FX/cross-border rules
SupportKnow SLAs for refunds, chargebacks, and reversals

Audit Checklist (Internal Readiness)

TLS 1.2+ enforced on all endpoints

No PAN/CVV in logs or response bodies

2FA enabled for all admin/card dashboard access

Internal card operations are audit-logged

Webhooks signed and verified

Refund/chargeback SLAs met 99% of the time

KYC enforced before spending on MCC 6051, 7995, 4829

Partner card scheme documentation accessible

Float exposure reviewed weekly

Compliance reviews logged quarterly

Module 9 Knowledge Check

1. What does PCI-DSS primarily govern?

A. Merchant payouts

B. Card issuance business models

C. Storage and transmission of cardholder data

D. Revenue reporting

Answer: C

2. What must you never store or log?

A. Merchant name

B. PAN/CVV in plaintext

C. MCC codes

D. BIN metadata

Answer: B

3. Which MCCs are considered high-risk and require compliance safeguards?

A. 5732 and 5812

B. 7995, 6051, 4829

C. 4411 and 4511

D. 5045, 5065

Answer: B