Your vendor controls
your compliance record.
Your communication records are under operator control. Under DORA and MiFID II, that means your vendor can alter the record your regulator relies on. No existing enterprise messaging platform — Bloomberg, Symphony, or Slack — can provide a tamper-evident record that is independent of the operator who runs the infrastructure. Bastion closes that gap.
Three sectors with the same structural gap.
If your regulatory obligations require communication records that are tamper-evident, attributable to authenticated parties, and independently verifiable — you are in the right place. If they do not, the protocol page has the detail you need.
Firms subject to DORA or MiFID II
Investment banks, trading desks, asset managers, and financial institutions whose communications are subject to regulatory record-keeping and incident communication requirements where operator-controlled records create regulatory and counterparty risk.
Organisations with HIPAA communication obligations
Hospitals, health systems, insurers, and healthcare technology companies whose communications involve protected health information and require demonstrable end-to-end confidentiality without relying on a vendor's assurance about server-side access.
Organisations with non-repudiation and privilege requirements
Law firms, in-house legal teams, defence contractors, and government organisations where cryptographic non-repudiation, legal privilege protection, and chain-of-custody integrity for communications are operational requirements — not preferences.
What the regulations require versus what platforms deliver.
Bloomberg Terminal, Symphony, and Slack are well-built products that genuinely satisfy archiving and record-retention requirements. This is not a criticism of those platforms. It is an observation that their architecture makes one requirement structurally impossible: a record that is independent of the operator who holds it.
| Requirement | Bloomberg Terminal | Symphony | Bastion |
|---|---|---|---|
|
Message retention & archiving
DORA · MiFID II · HIPAA
|
Bloomberg Vault — fully compliant archiving | Built-in compliance retention and eDiscovery | ML-DSA-signed messages anchored on BSV — permanent, timestamped |
|
Records independent of operator control
DORA Art. 11 · MiFID II Art. 25
|
Bloomberg controls the infrastructure — records are under vendor control | Symphony controls the infrastructure — same structural dependency | BSV PoW anchoring — no operator, including Bastion, can amend the record |
|
Cryptographic sender non-repudiation
MiFID II Art. 25 · Legal proceedings
|
Platform-level attribution — server asserts identity, not a user-held cryptographic key | Platform-level signatures — not user-key cryptographic proof | ML-DSA-87 — the sender's private key signed the message; verifiable by any party |
|
End-to-end confidentiality (no server-side plaintext)
HIPAA § 164.312 · Legal privilege
|
Bloomberg has access to message content — required for compliance archiving | E2EE option available, but compliance key escrow means a third party holds keys | AES-256-GCM with ratchet-derived keys — no server ever holds plaintext |
|
Compliance attestation without content disclosure
Cross-institutional regulated markets
|
Compliance proof requires content disclosure to Bloomberg | Compliance proof requires content disclosure to Symphony | Phase 3 — zk-STARK delivery receipts: prove delivery to an authenticated recipient without revealing content |
|
Quantum-resistant encryption
10-year confidentiality horizon
|
Classical encryption — vulnerable to harvest-now-decrypt-later | Classical encryption — same exposure | ML-KEM-1024 hybrid — quantum-resistant from day one |
Four properties the compliance gap requires.
Bastion provides the cryptographic record and non-repudiation layer. Your existing KYC and identity attestation infrastructure provides the legal identity binding — the mapping from cryptographic keypair to natural or legal person that DORA, MiFID II, and HIPAA require for attributing records to accountable parties. Together they close the compliance gap. Neither closes it alone.
Cryptographic non-repudiation at the user-key level
Every Bastion message is signed by the sender's ML-DSA-87 keypair over the complete wire payload — every security-relevant field, including identity, timestamp, and content hash. The signature is verifiable by any party with the sender's public key. The evidence does not depend on Bastion's infrastructure being available, cooperative, or uncompromised.
On-chain anchoring no operator can amend
Every anchored action is recorded on the BSV blockchain via OP_RETURN. The record is permanent and timestamped by the block. No party — including the Bastion operator — can modify an anchored record after the fact. A regulator, counterparty, or auditor can verify the record independently, without requesting it from Bastion.
End-to-end encryption with no server-side access
Messages are encrypted before leaving the sender's device. No server ever holds plaintext. Confidentiality is verifiable from the protocol design — AES-256-GCM with ratchet-derived keys, ML-KEM-1024 hybrid session establishment. The assurance is cryptographic, not contractual. Quantum-resistant from day one against harvest-now-decrypt-later collection.
Phase 3 — zk-STARK delivery receipts
Zero-knowledge proofs of delivery enable compliance attestation without disclosing message content: proof that a specific authenticated sender transmitted to a specific authenticated recipient at a specific time, without revealing what was communicated. This is the exact primitive required for cross-institutional compliance in regulated markets where counterparty communications are sensitive.
The gap, specific to your regulatory context.
DORA & MiFID II obligations
- DORA Article 11 requires ICT incident communication records that are tamper-evident and not under unilateral operator control
- MiFID II Article 25 requires immutable, timestamped records of transaction-related communications attributable to authenticated parties
- A regulator must be able to verify the record independently — not request it from the platform that holds it
- Counterparties must not be able to claim a record was altered after the fact
HIPAA confidentiality obligations
- HIPAA § 164.312 requires demonstrable end-to-end confidentiality of protected health information
- "Demonstrable" means verifiable from the technical design — not from a vendor's policy statement or audit certificate
- Server-side access by the platform operator creates a third-party access point that HIPAA's minimum necessary standard does not permit
- Compliance key escrow (as in Symphony's E2EE implementation) means a third party holds the keys to PHI
Non-repudiation & privilege requirements
- Legal privilege requires that communications between attorney and client cannot be accessed by a third party — including the platform operator
- Chain-of-custody integrity for communications used in proceedings requires that the record cannot have been altered between transmission and production
- Non-repudiation in defence and sensitive government contexts requires proof of identity at the cryptographic key level, not platform-level attribution
- Defence contractors may have obligations under export control regulations that require careful evaluation of cryptographic primitives used
Why the infrastructure choice is a compliance decision, not a technology preference.
The compliance gap cannot be closed by engineering on top of a platform that controls its own infrastructure. The record is only independent when the ledger it lives on is operated by no single party. That requires a public, permissionless blockchain with proof-of-work consensus — one where the record cannot be retroactively modified regardless of what any operator is instructed or compelled to do.
Bitcoin SV is a public proof-of-work blockchain with a fixed protocol specification completed by the Chronicle upgrade in 2024. Miners have known legal identities. The BSV Association is a non-profit steward actively participating in ISO/TC 307 — the international standards committee for blockchain and distributed ledger technology. TeraNode demonstrates one million transactions per second, providing the throughput required for protocol-scale action anchoring.
The current hashrate concentration and AWS infrastructure deployment are named constraints with a Phase 3 mitigation path involving multiple independent node operators across jurisdictions. Full detail is in the protocol whitepaper.
We will come to you prepared.
A Bastion briefing is a focused technical and regulatory conversation — not a sales call. Tell us your organisation's regulatory context and the specific gap you are trying to close. We will prepare accordingly.
Briefings are available for compliance officers, CISOs, in-house legal teams, and procurement leads at regulated institutions. If you are a systems engineer evaluating the protocol technically, the protocol page and whitepaper have the depth you need.
Current Phase 1 status: Reference implementation complete. 340 tests, 42/42 security gate checks, zero critical findings. Running on BSV testnet. Phase 2 (Rust core, TEE/HSM, FROST) is the active build.