Bastion Protocol · Regulated Industry
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.
01 · Who this is for
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 depth you need.
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.
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.
Law firms, in-house legal teams, defence contractors, and government organisations where cryptographic non-repudiation, legal privilege protection, and chain-of-custody integrity are operational requirements, not preferences.
02 · The compliance gap
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 & archivingDORA · 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 controlDORA Art. 11 · MiFID II Art. 25 | Bloomberg controls the infrastructure, so records are under vendor control | Symphony controls the infrastructure, the same structural dependency | PoW anchoring: no operator, including Bastion, can amend the record |
| Cryptographic sender non-repudiationMiFID II Art. 25 · legal proceedings | Platform-level attribution: the server asserts identity, not a user-held 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 plaintextHIPAA § 164.312 · legal privilege | Bloomberg has content access, required for compliance archiving | E2EE option exists, 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 disclosurecross-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 without revealing content |
| Quantum-resistant encryption10-year confidentiality horizon | Classical encryption, vulnerable to harvest-now-decrypt-later | Classical encryption, same exposure | ML-KEM-1024 hybrid: quantum-resistant from day one |
Bloomberg Terminal and Symphony are assessed fairly: both genuinely satisfy archiving and retention requirements for DORA, MiFID II, and HIPAA. The gap is structural, not a product flaw.
03 · How Bastion closes it
Bastion provides the cryptographic record and non-repudiation layer. Your existing KYC and identity-attestation infrastructure provides the legal identity binding: the mapping from a cryptographic keypair to a natural or legal person that DORA, MiFID II, and HIPAA require. Together they close the compliance gap. Neither closes it alone.
Every Bastion message is signed by the sender's ML-DSA-87 keypair over the complete wire payload, 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.
Every anchored action is recorded on BSV via OP_RETURN, 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 verifies the record independently, without requesting it from Bastion.
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, and quantum-resistant from day one.
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. The exact primitive cross-institutional compliance requires in regulated markets where counterparty communications are sensitive.
04 · Sector detail
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, and counterparties must not be able to claim a record was altered after the fact.
Bloomberg and Symphony satisfy archiving. Neither can satisfy independence from operator control. That gap is what Bastion closes.
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 the minimum-necessary standard does not permit; compliance key escrow (as in Symphony's E2EE) means a third party holds the keys to PHI.
The confidentiality assurance must be cryptographic and verifiable. Bastion's E2EE is provable from the protocol design. No key escrow. No server-side plaintext.
Legal privilege requires that attorney–client communications cannot be accessed by any third party, including the platform operator. Chain-of-custody integrity requires that a 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 additionally have export-control obligations requiring careful evaluation of the cryptographic primitives used.
ML-DSA-87 user-key signatures provide cryptographic non-repudiation. On-chain anchoring provides chain-of-custody integrity. No server-side access provides privilege protection.
05 · Infrastructure
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: a public, permissionless blockchain with proof-of-work consensus, 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, the throughput protocol-scale anchoring requires. 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 in the whitepaper.
| Property | State |
|---|---|
| Protocol specification | Fixed · Chronicle 2024 |
| Miner identity | Known legal identities |
| Demonstrated throughput | 1M TPS · TeraNode |
| Standards participation | ISO/TC 307 |
| OP_RETURN data anchoring | Unbounded payload |
| Consensus mechanism | Proof-of-work |
| Steward organisation | BSV Association · non-profit |
| Privacy-coin features | None · full auditability |
06 · Request a briefing
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 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 status: Phase 1 reference implementation complete: 340 tests, 42/42 gate checks, zero critical findings, running on BSV testnet. Phase 2 (Rust core, TEE/HSM, FROST) is the active build.