EMV card profile
Certification for personalized and instant cards, contact and contactless, per the scheme's profile requirements.
Card Prime / Integration
Every interface is its own project.
Each external system gets a plan, environments, test cases and exit criteria. The workstream runs in parallel with the product phases and gates each go-live.
Interfaces
What the card system talks to.
| Source | Destination | Protocol | Purpose |
|---|---|---|---|
| CARD PRIME D 3.0 | HSM | Host command channel | PIN, CVV and key operations |
| CARD PRIME D 3.0 | Core banking | ISO 8583 or REST over TLS | Authorization, posting, reversals |
| CARD PRIME D 3.0 | Mastercard MDES | Scheme API over mTLS | Token lifecycle for digital cards |
| CARD PRIME D 3.0 | Embossing vendors | SFTP + PGP | Perso files and acknowledgements |
| CARD PRIME D 3.0 | SMS / e-mail gateway | SMPP / SMTP / REST | Advice, OTP, alerts |
| CARD PRIME D 3.0 / T-NET | AML system | REST / ISO 8583 hook | Transaction and customer screening |
| Gen ATM ATM Service | CARD PRIME D 3.0 | REST / internal ISO 8583 | Cardholder, status and limits lookup |
Certification
What has to pass first.
Mastercard MDES
Issuer enrolment and token lifecycle testing, on the scheme's onboarding timeline.
Scheme authorization
Incoming and outgoing authorization and clearing certification, scheduled against the scheme calendar.
PCI DSS
Alignment of the cardholder data environment, with formal assessment by the institution's QSA and support from our side.
What we need from you
Scheme membership or sponsorship, BIN ranges and certification slots; the core banking interface specification and a test environment; HSM appliances and key-ceremony participation; embossing vendor contracts and PGP keys; instant card stock; KIOSK hardware; and access to your mobile app team for the SDK.
Deployment
On-premises, in your data centre.
Separate UAT, production and DR environments. All card, transaction and audit data stays inside your environment — the licence is perpetual and the platform is yours to operate.
| Node group | Qty | Specification | Zone |
|---|---|---|---|
| Application nodes | 3 | 8 vCPU · 32 GB RAM · 300 GB — CARD PRIME D, Gen ATM NGK, UMS | Internal |
| Switch nodes (T-NET) | 2 | 8 vCPU · 16 GB RAM · 200 GB — active/active | DMZ / switch zone |
| Database | 2 | 8 vCPU · 64 GB RAM · 1 TB SSD — primary/standby | Internal |
| Messaging & cache | 3 | 4 vCPU · 16 GB RAM · 200 GB — Kafka, Redis | Internal |
| HSM | 2 | payShield-class HA pair, plus one at DR | Security zone |
| DR | 1 set | Mirror of production · RPO ≤ 15 min · RTO ≤ 4 h (target) | DR site |
Technology baseline: Java / Spring Boot microservices, PostgreSQL 16 (Oracle 19c supported), Kafka, Redis, REST with OpenAPI and ISO 8583. Availability target 99.9% excluding planned maintenance; internal switch processing under 300 ms.
Multi-institution
One installation, several licensed entities.
Each institution carries its own BIN ranges, card products, limits, fee and GL mapping, settlement identity, users, branding and reporting — under one operations team. Segregation is by an institution key on every record and by role scoping in the back office.
Base product licence
One licence for the installation itself.
Institution licence
One per licensed legal entity processed on the platform.
Capacity licence
Grows with the ATMs under management and the active card base.
Next step
Put a card in a customer's hand today.
Tell us your BIN plan, card products and where the customer starts — branch, KIOSK or app. We will come back with an issuance design, an embossing plan and a delivery schedule.