Cards & Issuing: A White Paper on Modern, Regulated Card Programs
Issuing virtual and physical cards on a regulated, cryptographically future-proof foundation
Card programs have become a primary way credit unions, community banks, and health systems engage members, customers, and patients. Yet many issuing stacks were assembled from aging processor integrations, opaque token handling, and cryptography that predates the quantum era. This paper sets out the problem, ACM's architecture for white-label issuing, and a security and compliance posture written to be defensible under scrutiny rather than overstated.
Why card issuing is harder than it looks
Launching a card looks like a product decision. Operating one safely is an infrastructure and compliance decision that compounds over the life of every account.
Fragmented stacks
Issuing, processing, tokenization, fraud, ledgering, and dispute handling often live in separate systems stitched together by batch files and brittle middleware. Each seam adds latency, reconciliation risk, and a place for sensitive data to leak.
PAN sprawl
When the Primary Account Number (the 13-to-19-digit card number) flows through more systems than it should, PCI-DSS scope expands, audits lengthen, and the blast radius of any breach grows with it.
Slow time-to-launch
For a credit union or community bank, standing up a new card program can mean quarters of integration work before the first card is provisioned, and more before changes can ship safely.
Cryptography with a shelf life
Card data and transaction records are long-lived. Encryption that is adequate today may not protect data captured now and decrypted later, once cryptographically relevant quantum computers arrive. This "harvest-now, decrypt-later" exposure is widely discussed across the security community.
One regulated platform, virtual and physical
ACM provides Cards & Issuing as part of a complete, white-label banking technology ecosystem, so issuing shares the same core, ledger, treasury, and identity primitives rather than bolting onto them.
Virtual-first provisioning
Virtual cards can be created programmatically and made available to a cardholder's wallet immediately, with controls for spend limits, merchant categories, single-use numbers, and lifecycle events such as freeze, replace, and close.
Physical card programs
The same program model extends to physical issuance, so a card's digital and plastic forms reference one account and one set of controls, keeping the cardholder experience and the audit trail consistent.
Tokenization at the center
ACM is designed around the EMVCo Payment Tokenisation model, in which the PAN is replaced by a surrogate token. Tokens can be scoped so that a value captured in one context cannot be replayed elsewhere, narrowing how far sensitive data travels.
White-label by default
The institution owns the brand and the relationship. ACM supplies the technology underneath, so a credit union, community bank, or health system can issue under its own name without operating a card platform from scratch.
How the pieces fit together
The reference architecture separates concerns deliberately, so sensitive data is concentrated where it can be defended and kept out of systems that do not need it.
- API-first issuing service. Card creation, activation, controls, and lifecycle actions are driven through documented APIs and events, so programs can be automated and changed without re-platforming.
- Token vault and detokenization boundary. Mapping between a token and the underlying PAN is confined to a hardened boundary, consistent with the Token Service Provider model, rather than exposed to application code.
- Shared ledger and treasury. Because issuing runs on ACM's core, authorizations, postings, settlement, and reconciliation reference one source of truth instead of a separately maintained copy.
- Real-time controls and events. Spend rules, status changes, and notifications are evaluated as transactions occur, giving risk and operations teams immediate signal rather than next-day batch insight.
- Non-custodial key management. ACM applies threshold cryptography and non-custodial key management so that no single party or component holds complete control of sensitive keys, reducing the consequence of any one compromise.
A posture built to be defended, not declared
ACM does not claim certifications it does not hold. The platform is engineered to support recognized control frameworks so that an institution's own audits start from a sound technical baseline.
Compliance-ready by design
The architecture is designed to support SOC 2, ISO 27001, PCI-DSS, and, for health-adjacent use cases, HIPAA requirements. Tokenization and tight data boundaries are intended to reduce PCI-DSS scope rather than spread it.
Aligned to NIST post-quantum standards
In 2024 NIST finalized its first post-quantum standards: ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for digital signatures. These standards are recent; ACM's role is to build on and align to them as it modernizes the cryptography protecting long-lived card data.
Crypto-agility
Because card records persist for years, ACM treats cryptography as something to be upgraded over time. Designing for algorithm agility is intended to ease migration toward post-quantum primitives without re-architecting the platform.
Layered controls
Tokenization, threshold key management, scoped credentials, and real-time monitoring are layered so that a weakness in one control does not by itself expose cardholder data.
From integration to issued card
ACM is built to meet institutions where they are, whether they are launching a first program or modernizing an existing one, using an Agile Speed Framework to keep delivery predictable.
- API and event integration. Connect issuing, controls, and lifecycle events to existing banking, mobile, and fraud systems through documented interfaces.
- Banking-as-a-Service path. Institutions can consume issuing as part of ACM's BaaS offering, reducing the operational surface they run themselves.
- Deployment flexibility. The platform is designed for regulated environments and can be deployed to align with an institution's data-residency, segregation, and oversight requirements.
- Phased rollout. Programs can begin with virtual issuance to a limited cohort and expand to physical cards and broader populations as controls and operations are validated.
- Ecosystem extensions. Where institutions want agentic automation or tokenized settlement, ACM's ecosystem partners Hanzo.ai and Lux Network / Lux Network provide complementary capabilities.
What institutions can reasonably expect
Outcomes depend on each institution's starting point, program design, and integration choices. We frame benefits as engineering goals, not guarantees.
Reduced compliance surface
By keeping the PAN inside a token vault and out of application systems, the architecture is designed to narrow PCI-DSS scope and simplify the evidence an institution must gather at audit.
Lower infrastructure cost
Consolidating issuing onto a shared modern core is how ACM targets up to 95% lower infrastructure cost versus legacy core systems. Actual savings vary by deployment and migration scope.
Faster, safer change
API-driven programs and the Agile Speed Framework are intended to shorten the path from idea to issued card, and to make ongoing changes routine rather than risky.
Durable data protection
Crypto-agility and alignment to NIST post-quantum standards are aimed at protecting card data across its full retention life, including against harvest-now, decrypt-later exposure.
Related work in the ecosystem
These independent research sources explore adjacent topics in agentic AI and tokenized finance. They are provided as related reading, not as endorsements or ACM claims.
- Hanzo.ai research: agentic AI and applied machine learning, at papers.hanzo.ai.
- Lux Network: tokenized finance and settlement infrastructure, at lux.network.
- ACM capabilities: see post-quantum security and our trust and compliance posture for how these ideas apply to regulated card programs.
Design your card program with a regulated foundation
Talk to our team about virtual and physical issuing, tokenization, and a security posture engineered to support PCI-DSS, SOC 2, ISO 27001, and HIPAA requirements while aligning to NIST post-quantum standards.
Start a discovery callFrequently asked questions
Does ACM issue both virtual and physical cards?
Yes. ACM's Cards & Issuing supports virtual cards that can be provisioned programmatically to a cardholder's wallet, as well as physical card programs. Both reference the same account, controls, and audit trail, so the digital and plastic forms of a card stay consistent.
How does ACM reduce PCI-DSS scope for card data?
ACM is designed around the EMVCo Payment Tokenisation model, which replaces the Primary Account Number with a surrogate token, and confines detokenization to a hardened token-vault boundary consistent with the Token Service Provider model. Keeping the PAN out of application systems is intended to narrow PCI-DSS scope. ACM's platform is designed to support PCI-DSS, SOC 2, ISO 27001, and HIPAA requirements; it does not hold or claim those certifications on a customer's behalf.
Is the card platform post-quantum ready?
ACM aligns to the post-quantum standards NIST finalized in 2024, including ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). These standards are recent, so ACM frames its work as building on and migrating toward them with crypto-agility, aimed at protecting long-lived card data against harvest-now, decrypt-later risk rather than as a finished guarantee.