From card proposition to live operation

Card programmes often begin with visible features: a physical card, rewards, limits, or a mobile wallet. Delivery succeeds or fails in the less visible connections between product decisions, regulated roles, processors, schemes, token services, fraud controls, customer operations, certification, and live support.

A product specification is not yet a delivery model

The proposition should be stated in operational terms: who the customer is, where they are served, how the account is funded, which transactions are supported, how authorisation decisions are made, what the customer sees, and which party remains accountable at each stage. Those choices determine the supplier model, economics, risk controls, technical design, and delivery sequence.

The exact regulatory and scheme position depends on the activity, market, legal entities, programme structure, and partner roles. The useful starting point is therefore a role-and-decision map, supported by qualified advisers where a legal, regulatory, or scheme conclusion is required.

Make the proposition testable

Replace broad product language with observable rules. Define supported customer types and countries, funding and settlement currencies, transaction channels, limits, controls, pricing events, disputes, replacement, closure, and service levels. Identify which features are required for launch, which can follow, and which create disproportionate complexity.

This creates acceptance criteria. A premium experience, for example, should translate into specific onboarding, provisioning, authorisation, notification, support, dispute, and replacement behaviours rather than visual design alone.

Define operating roles before selecting components

A programme can involve an issuer or sponsor, processor, scheme, manufacturer, token service, wallet platform, fraud tooling, customer support, and several internal teams. The labels vary by model. What matters is that every material decision, record, control, incident, and customer outcome has an accountable owner.

The map should cover normal operation and change: who approves product rules, configures authorisation, manages keys and credentials, monitors fraud, controls card stock, resolves disputes, handles compromised accounts, approves releases, and coordinates incidents. Supplier selection becomes more reliable once these hand-offs are visible.

Design the credential lifecycle, not only card issuance

EMVCo describes a payment token as a surrogate value that replaces a primary account number and can be constrained to a particular merchant, device, or payment scenario. Its technical framework defines roles, functions, and requirements for introducing payment tokens into the existing payment ecosystem.¹

The programme therefore needs lifecycle decisions for the underlying account, physical credential, and device or merchant tokens. Provisioning, identity verification, activation, suspension, replacement, renewal, device change, account update, compromise, and closure must remain coordinated even where different providers execute them.

Apple’s security documentation explains that, after approval, the bank, issuer, or authorised service provider creates a device-specific account number and that transactions use it with a transaction-specific dynamic security code.⁵ Google’s merchant documentation describes signed and encrypted payment-method tokens and distinguishes tokenised device credentials from primary-account-number flows.⁶ These implementations differ, but both demonstrate why “enable the wallet” is not a complete operating requirement.

Design authentication, fraud controls, and customer experience together

EMV 3-D Secure enables transaction, payment-method, and device data to pass between merchant-side participants and the issuer for cardholder authentication. The issuer can allow a lower-friction flow or require a challenge where additional authentication is needed.²

In the EEA, the strong-customer-authentication framework requires transaction monitoring and provides specified, conditional exemptions, including transaction-risk analysis subject to fraud-rate thresholds and real-time risk factors.³ The practical design question is not simply whether a transaction is authenticated. It is whether the data, decision rules, challenge journey, exemptions, fraud monitoring, and customer communication operate coherently.

Establish security scope before final architecture

PCI DSS provides technical and operational requirements for protecting payment account data. The PCI Security Standards Council publishes version 4.0.1 and its associated reporting and self-assessment materials in the official document library.⁴

The programme should establish which systems, people, locations, and providers store, process, transmit, or can affect the security of payment account data. That scoping decision influences integrations, operating procedures, evidence, supplier responsibilities, testing, and the validation route. Tokenisation can change exposure, but it should not be treated as a universal exemption from security responsibilities.

Plan certification and readiness as delivery workstreams

Scheme, processor, card, wallet, security, and regulatory readiness can require different evidence, environments, test cases, and approval sequences. A single “certification” milestone can conceal dependencies that only become visible late in the programme.

Maintain one integrated plan showing owners, entry criteria, test data, environments, external lead times, defect thresholds, evidence, and decisions. Operational readiness should run alongside technical completion and cover customer support, disputes, fraud operations, monitoring, finance, reconciliation, incident response, stock, suppliers, and controlled change.

Launch with an operating baseline

The launch decision should identify what is proven, what remains constrained, and who owns each residual risk. Early-life monitoring should measure technical availability alongside authorisation performance, fraud, provisioning success, customer contacts, disputes, settlement, reconciliation, and supplier incidents.

The baseline also matters after launch. Product expansion, new wallets, rule changes, processor releases, new markets, and supplier changes should be evaluated against the same proposition, role, credential, security, and operating model rather than introduced as isolated projects.

One launch record

Before go-live, the accountable body should be able to review:

• the proposition, customer, market, and launch scope;
• the entity, supplier, scheme, and operating-role map;
• the account, card, token, and wallet lifecycle;
• authentication, authorisation, fraud, and limit decisions;
• data-security scope, responsibilities, and evidence;
• certification status and unresolved conditions;
• customer, financial, operational, and incident readiness; and
• the early-life monitoring and change model.

The objective is not to make every programme structurally identical. It is to prevent a strong proposition from being weakened by unowned hand-offs between the decisions that take it into operation.