DUKPT, per transaction
The PIN block is created on the terminal under a key derived for that transaction and translated only inside the HSM. Clear PIN values never exist in the application tier and are never stored.
T-NET / Security
The application holds references. The module holds keys.
Security here is a property of where things live, not a policy someone has to remember to enforce.
MAC on every message
A message authentication code is generated and verified on every inter-switch message. Working keys are wrapped by a dual-component zone master key with key check values, rotated through network-management messages under dual control.
Masked and tokenised
PANs are masked across screens, reports, logs and APIs. Card references are tokenised for cross-system use and sensitive fields are encrypted at rest.
Two databases
Transaction records are held in a separate sensitive database from configuration data, with restricted credentials and its own retention and access policy.
Domain separation
The acquiring command set is not the issuing command set.
The same installation runs issuing, ATM and acquiring. The HSM service that serves this switch exposes an acquiring command set isolated from the issuing and ATM commands — so a compromise of one domain does not become a compromise of the others.
- PIN translation from the terminal's DUKPT base derivation key to the scheme working key
- PIN translation between working keys, and PIN verification
- MAC generation and verification on every inter-switch message
- EMV cryptogram services and data-block encryption
- Key ceremonies under dual control, per the institution's security policy
What this rules out
Because PIN operations happen only inside the hardware module and the acquiring command set is isolated, there is no log level, no debug flag and no support procedure that can expose a PIN from this switch. That is a property of the design rather than something an operator has to get right every day.
API security
Every surface, the same rules.
- JWT with expiry and a blacklist, so a revoked token stops working immediately
- Time-based one-time passwords where the operation warrants a second factor
- Rate limiting per credential and per surface
- Audit logging on every API call, with the acting identity recorded
- Full audit trail and maker-checker on merchant, terminal, fee and configuration changes
- Segregation of duties by role, institution and merchant
Certification
What has to pass, and who owns it.
| Certification | Scope | Owner |
|---|---|---|
| Scheme acquiring | Authorization and clearing certification, per the scheme calendar | TantraFino + scheme |
| EMV Level 3 | Per card scheme, for each terminal model and kernel configuration in the estate | TantraFino + scheme + POS vendor |
| PCI DSS | Alignment of the cardholder-data environment; formal assessment by the institution's QSA | Institution's QSA, with our support |
| PCI PIN & key injection | Remote key injection procedures under dual control with the POS and HSM vendors | TantraFino + vendors |
| PCI P2PE | Only if the institution elects that scope | Institution |
| EMVCo QR | Conformance for the customer- and merchant-presented payloads | TantraFino + EMVCo scheme programme |
Next step
Send us your message spec. We will send back a profile.
Your scheme endpoint, your CBS interface and your terminal mix are enough for us to come back with an ISO 8583 packaging profile, a sizing note and a certification schedule.