Owned by the card networks, not elected or appointed to the job
EMVCo took its name from its three founders — Europay, Mastercard, and Visa — when it was formed in 1999 to maintain the chip-card specifications those networks had each been developing separately. Europay was later absorbed into Mastercard, and EMVCo is now owned in equal shares by six members: Visa, Mastercard, American Express, Discover, JCB, and UnionPay. This is a fundamentally different model from every other body on this page: NIST is a government agency, the IETF is open to any individual, ISO/IEC is a federation of national bodies, and OASIS is a vendor consortium anyone can join — EMVCo is owned outright by the handful of companies whose cards the specification governs.
The specifications themselves are free to download from EMVCo's website, which can make the organization look more open than it is. The part that isn't open is conformance: a terminal, card, or payment application can't simply claim EMV compliance — it has to pass testing at an EMVCo-approved laboratory against EMVCo's own test suites, and EMVCo (meaning, ultimately, its six owner networks) controls who gets to run those labs and what the test suites cover.
What EMVCo has actually standardized
Every Payments use case and Playground tool on this site traces back to one of these.
EMVCo specifications behind this site's Payments chapter
The core chip-card specification — application selection, card-terminal data interchange, security and key management, cardholder/application selection. This is where ARQC/ARPC and ICC key derivation live.
The AReq/ARes authentication-request protocol covered in the 3DS Playground tool — JSON messages, JWS signing, the frictionless-vs-challenge decision.
Domain-bound tokens, Token Requestor IDs, and the token vault model covered in the network tokenization tool.
Practice
A payment terminal vendor wants to claim EMV compliance. Is downloading the EMV Books from EMVCo's website and implementing them enough?
Go deeperThe part EMVCo deliberately leaves unpublished⌄
Unlike NIST, which publishes complete algorithms down to the test vector, EMVCo's own specifications leave certain cryptographic constructions issuer- or network-proprietary by design — most notably CAVV generation in 3-D Secure and the token cryptogram in network tokenization. The EMV Books specify what a CAVV or token cryptogram has to achieve (a value the issuer or network can verify, bound to a specific transaction) without specifying exactly how any given network computes it. This is a real, structural difference from the PIN block, CVV, and ARQC algorithms covered elsewhere in this catalog, which are fully public — and it's exactly why this site's own CAVV and token-cryptogram Playground tools are labeled as illustrative constructions rather than real algorithms: there's no public specification to implement faithfully in the first place.
PCI SSC: compliance enforcement, not algorithm design
The PCI Security Standards Council was formed in 2006 by five card brands — Visa, Mastercard, American Express, Discover, and JCB — to run a separate, complementary function: not designing cryptographic protocols the way EMVCo does, but setting the security and operational requirements for anyone who stores, processes, or transmits cardholder data, and overseeing how compliance with those requirements gets assessed.
PCI DSS (the Data Security Standard) is the best-known output and the one referenced throughout this site's CVV use case — it's the standard that prohibits storing a CVV after authorization. PCI PIN Security Requirements governs how PIN blocks, TPKs, and ZPKs have to be handled end to end, directly underpinning the PIN block use case. PCI P2PE (Point-to-Point Encryption) and the PCI 3DS Core Security Standard round out the set that touches this catalog's Payments chapter.
EMVCo
- •Designs the protocols and data formats themselves — what an ARQC contains, how a 3DS message is structured
- •Owned by the six card networks directly
- •Conformance tested at EMVCo-approved labs
PCI SSC
- •Sets security and operational requirements for anyone handling card data — how keys must be protected, what can never be stored
- •Founded by five card brands, broader industry participation in standard development
- •Compliance assessed by Qualified Security Assessors (QSAs), enforced through the card networks' own merchant/processor contracts rather than by law
Practice
A company stores full CVV values in its database after completing each transaction's authorization, "just in case" a dispute comes up later. Which standard does this most directly violate — an EMVCo specification, or a PCI SSC one?
Go deeperWhy compliance isn't "law" but isn't optional either⌄
Neither EMVCo's specifications nor PCI DSS are government regulations — no legislature passed them, and no regulator directly enforces them the way a financial regulator enforces banking law. Their force comes from contract: merchants and processors agree to the card networks' own operating rules as a condition of being allowed to accept Visa, Mastercard, and the others' cards at all, and those operating rules incorporate EMVCo and PCI SSC compliance by reference. The practical effect — fines, increased transaction fees, or losing the ability to process cards at all for serious or repeated non-compliance — makes compliance effectively mandatory for any business that wants to keep accepting card payments, even though the mechanism is private contract law rather than statute.