EMV
Cryptography for the physical card and the transaction.
- You contract
- Key management, cryptographic card preparation and PIN, CVV and EMV cryptogram validation during authorisation.
- Connects to
- Authoriser and bureau
Architecture connected to the issuer’s operation
The authoriser, back office, bureau and channels stay in place. MILETIA connects the cryptographic core required to issue, personalise and validate physical and digital cards.
From credential to decision
Chip cards, NFC cards and NFC devices travel through the same acceptance network to the authoriser. In the credential flow, the device connects alternatively to Your Wallet or to Google Pay, Samsung Pay and Apple Pay; the selected option connects to the NFC module.
Transaction flow: Chip card, NFC card or NFC device, POS, Acquiring network, Authoriser, MILETIA CaaS.
query ↔ result. CDE ↔ Back office and Portals; EMV ↔ Chosen bureau; NFC device → Your Wallet (NFC WITH THE MILETIA SDK) or Google Pay, Samsung Pay or Apple Pay → NFC.
What the issuer contracts
A modular service layer operated by MILETIA and consumed through APIs. Each module takes on a specific responsibility without replacing the platform that already runs the issuer’s business.
CDE
A secure perimeter for card data and lifecycle.
- You contract
- PAN generation and tokenisation, PIN enrolment, activation, suspension and cancellation, with an operational trail.
- Connects to
- Back office and portals
NFC
Digital credentials for the issuer’s own wallet.
- You contract
- DPAN and device-key provisioning, token lifecycle and contactless cryptogram validation.
- Connects to
- App, backend and authoriser
EMV and CDE can be contracted independently. NFC requires EMV because the digital credential depends on the card’s cryptographic keys and validation.
The division of responsibilities stays clear
MILETIA adds cryptographic capability. The issuer keeps control of the product, the financial authorisation and the cardholder experience.
Stays with the issuer
- Authoriser and the final decision to approve or decline a transaction
- Balance, limits, ledger, product rules and fraud engine
- Back office, channels, support and cardholder experience
- Existing operation and choice of personalisation and acquiring partners
MILETIA operates
- The contracted PAN, token, PIN and NFC credential lifecycles
- Keys and cryptographic operations required for issuance and authorisation
- Data Preparation generation, protection, delivery and tracking
- Technical trails and per-issuer segregation of sensitive data
Three journeys in detail
Integration happens where the operation already needs cryptography. The financial path stays the same; CaaS enters as a specialised call.
Issuance and personalisation
From the back-office request to a card ready for use.
- 1
Card request
The back office provides the product, BIN and information required for issuance.
- 2
Secure creation
CaaS creates the PAN, token, PIN and cryptographic material for the contracted modules.
- 3
Personalisation
Protected Data Preparation is assembled, sent to the chosen bureau and tracked through its return.
- 4
Token-based management
The back office receives the token and status to operate the card without retaining the PAN.
Purchase authorisation
The authoriser keeps the decision; CaaS provides the cryptographic proof.
- 1
Transaction received
The acquiring flow delivers the transaction to the authoriser already used by the issuer.
- 2
Business rules
The authoriser checks balance, limits, status, product and fraud controls.
- 3
Cryptographic validation
The authoriser calls CaaS to validate PIN, CVV or ARQC and obtain ARPC when applicable.
- 4
Issuer decision
With the cryptographic result, the authoriser approves or declines and responds through the existing path.
NFC provisioning and use
The issuer’s wallet gains digital credentials connected to the same authorisation flow.
- 1
Channel request
The issuer’s app and backend start provisioning the card onto the device.
- 2
Digital credential
CaaS issues the DPAN and device keys without exposing the PAN to the channel.
- 3
Lifecycle
Activation, suspension, reactivation and cancellation follow the credential’s state.
- 4
Contactless purchase
The NFC cryptogram is validated while the authoriser retains the transaction’s financial decision.
Authorisation remains yours
CaaS confirms whether the credential, PIN, CVV or cryptogram is authentic. Balance, limits, risk and commercial rules — and the final decision — remain with the issuer’s authoriser.
What supports the service
The architecture adds capability without transferring operational complexity to the issuer.
- Integration
- APIs at issuance, management, personalisation and authorisation points, with no migration of the issuer’s operational database.
- Segregation
- Data, credentials and trails isolated per issuer, with individual access governance.
- Continuity
- Centralised operation and service evolution with no platform version for the issuer to maintain.
- Performance
- Multi-tenancy validated under a load of 1,500 transactions per second, with p95 latency below 50 ms.
- Traceability
- Each sensitive operation generates technical context and a trail without carrying sensitive data in operational events.
Security applied to the design
Security appears in the separation of responsibilities and in reducing the places where data and keys need to exist.
Sensitive data contained
PAN, PIN and cryptographic material stay inside the service perimeter; other systems work with tokens and validation results.
Specialised cryptography
Key and PIN operations run in FIPS 140-2 Level 3 certified payment HSMs, with ceremony and segregation controls.
Recognised references
Principles and controls from ISO/IEC 27001:2022, PCI DSS v4.0.1 and PCI PIN guide the CaaS design and operation.
Mentioning ISO/IEC 27001, PCI DSS and PCI PIN does not represent certification, validated compliance or an Attestation of Compliance (AoC). The scope applicable to each issuer depends on a formal assessment of its environment.
Map the integration points
In a technical assessment, MILETIA identifies which modules enter your flow, which systems stay in place and where each call connects to issuance and authorisation.