Keys stay apart.
The non-exportable device share is bound to Secure Enclave / StrongBox. The platform share stays under HSM/KMS envelope encryption in the bank.
Trust Center
A clear view of controls and evidence.
Understand the custody design, the scope of assurance and the materials your bank can verify during deployment.
Security built into the operating model.
Both shares sign.
2-of-2 MPC uses threshold ECDSA (DKLS23) for secp256k1 chains and FROST (RFC 9591) for Ed25519 chains.
Policy comes before movement.
The policy engine applies maker-checker approvals, whitelists and limits before assets move.
See the transaction you sign.
The mobile cosigner requires biometric approval. What you see is what you sign.
Refresh shares. Stop operations.
Proactive share refresh renews key shares. The kill switch lets the bank stop operations.
Recovery stays with the customer.
Customer-controlled recovery uses two escrow holders, keeping recovery authority separate from day-to-day signing.
What your bank keeps control of.
Fortiva is installed in your infrastructure and operated by your teams. These are the six areas where that control is concrete.
Keys
Both shares are created and held inside the bank's perimeter: one on the approver's device, one under HSM/KMS envelope encryption in the data centre.
Deployment
The platform runs in the bank's own data centre with no foreign SaaS dependency. Updates are applied on the bank's schedule.
Policies
Whitelists, limits, approval quorums and the kill switch are configured by the bank's administrators, vault by vault.
Recovery
Recovery follows the bank's documented procedure with two escrow holders of its choosing.
Releases
Signed images, SBOM and reproducible build inputs let the bank verify every release before it reaches production. Source code escrow backs the licence.
Evidence
The immutable evidence log, the controls matrix and the independent audit reports are available to the bank's auditors under NDA.
Standards, protocols and control mappings.
Protocol references and control mappings. These are not product certifications.
| Regulatory framework | Fortiva control mapping | Evidence status |
|---|---|---|
| NIST IR 8214 | Threshold cryptography architecture alignment. | Control mapping |
| DKLS23 | Threshold ECDSA for secp256k1 chains. | Protocol reference |
| FROST (RFC 9591) | Threshold signing for Ed25519 chains. | Protocol reference |
| FIPS 140-3 HSM | Hardware protection reference for the bank-selected HSM. Validation depends on the deployed hardware and configuration. | Hardware-dependent validation |
| CCSS | Key lifecycle, access separation and recovery control mapping. | Control mapping |
| ISO/IEC 27001 | Access control, logging and operational security controls mapping. | Control mapping |
| TÜBİTAK | Information-systems criteria mapped to deployment controls and evidence. | Control mapping |
| Independent security audit | Seven-phase independent security audit completed. | Completed security audit |
| Independent cryptography audit | Included in every deployment scope. | Deployment-scoped cryptography audit |
Designed for applicable custody requirements.
Control mappings cover Türkiye’s SPK custody permits, MASAK Travel Rule and TÜBİTAK information-systems criteria, alongside EU MiCA, UAE VARA / ADGM, Qatar QFC and Bahrain CBB. These are design and mapping references, not certifications or licences.
Fortiva is a software vendor, not a licensed custodian.
Review the compliance mappingsRelease materials the bank can verify.
Signed images, SBOM and reproducible build inputs support the bank’s release verification. Deployment is in the bank’s own data centre, without a foreign SaaS dependency, with source code escrow and sandbox access for the bank’s engineers.
Recovery authority remains with the customer.
Two escrow holders support customer-controlled recovery. Proactive share refresh renews the shares; the kill switch provides an operational stop. Recovery design and acceptance exercises are part of the deployment discussion.
Business Continuity