Financial fraud costs the global banking industry hundreds of billions of dollars annually. A significant portion of this fraud exploits the information silos between banks. A fraudster who opens accounts at five banks and distributes fraudulent transactions across all five can stay below the detection thresholds at each individual bank. Each bank sees only a fraction of the fraudulent activity, not enough to trigger an alert. But collectively, the pattern is obvious.
Banks know this. Regulators know this. The solution seems straightforward: share transaction data across banks and run fraud detection on the combined dataset. But data sharing between banks is legally complex, competitively risky, and technically challenging. Customer transaction data is among the most sensitive data a bank holds. Sharing it with competitors, even for fraud prevention, creates regulatory risk under GDPR, CCPA, and sector-specific regulations like the Gramm-Leach-Bliley Act.
The result is a stalemate. Banks want cross-institutional fraud detection. Regulations prevent cross-institutional data sharing. The fraud persists because the information silos persist. Fully homomorphic encryption breaks this stalemate by enabling computation across banks' encrypted data without any bank sharing plaintext customer information.
The Consortium Model
H33-Share enables a consortium model where multiple banks contribute encrypted transaction data to a shared fraud detection computation. The model works as follows:
Each participating bank encrypts its transaction data using FHE with its own encryption key. The encrypted transactions are submitted to H33's computation service. H33 runs the fraud detection model on all encrypted transactions simultaneously, evaluating cross-bank patterns in encrypted space. Each bank receives only its own fraud scores, encrypted under its own key. No bank sees another bank's transaction data, fraud scores, or customer information.
The computation service (H33) never decrypts any bank's data. It performs polynomial arithmetic on ciphertexts without understanding what the polynomials represent. Even a complete compromise of H33's infrastructure reveals nothing about any bank's customer transactions, because H33 never possesses any bank's decryption key.
The fraud detection model evaluates several cross-bank signals: velocity of account openings across the consortium (a single identity opening accounts at multiple banks in a short period), transaction patterns that distribute activity across banks to avoid per-bank thresholds, address and identity reuse across institutions, and temporal correlations between transactions at different banks that suggest coordinated fraudulent activity.
Technical Architecture
The cross-bank fraud detection system uses BFV homomorphic encryption with 4096 SIMD slots. Each bank encodes its transactions as feature vectors, where each feature represents a transaction attribute: amount, timestamp, category, location hash, and derived features like transaction velocity and account age. The feature vectors are encrypted and packed into ciphertexts with 32 transactions per ciphertext using the SIMD slots.
The fraud detection model is a combination of statistical anomaly detection and learned pattern matching. The statistical component computes encrypted aggregates across the consortium: total transaction volume per identity hash, number of unique institutions per identity, transaction velocity across institutions, and similar cross-bank metrics. These aggregates are compared against encrypted thresholds to flag anomalous identities.
The pattern matching component uses encrypted inner products to compare each identity's cross-bank transaction pattern against known fraud patterns. The fraud patterns are encoded as reference vectors, and the similarity between each identity's encrypted feature vector and each reference vector is computed homomorphically. High similarity scores indicate potential fraud.
Both components produce encrypted fraud scores that are returned to the originating bank. The bank decrypts the scores locally and integrates them into its existing fraud investigation workflow. The cross-bank scores complement the bank's internal fraud scores, providing additional signal that was previously unavailable.
Privacy Guarantees
The privacy model ensures that each bank learns only three things: its own transaction data (which it already knows), its own fraud scores (which are derived from the cross-bank analysis), and the total consortium size (which is public information). Each bank does not learn: other banks' transaction data, other banks' fraud scores, which other banks flagged which transactions, or the composition of the fraud detection model beyond what is publicly documented.
The computation service (H33) learns none of the above. It processes encrypted polynomials without understanding their semantic content. It cannot determine which ciphertexts belong to which bank (they are shuffled before submission), what values the ciphertexts encode, or what the computed fraud scores are.
The post-quantum attestation ensures that each bank can verify that the agreed-upon fraud detection model was applied to the full consortium's encrypted data. The 74-byte H33-74 token accompanying each fraud score proves that: the specific computation graph (fraud detection model) was executed, all participating banks' encrypted data was included in the computation, the computation was performed on the specific input ciphertexts, and the output was derived from the actual computation, not fabricated.
Regulatory Landscape
Cross-bank data sharing for fraud detection exists in various forms today. FinCEN's 314(b) program in the United States allows financial institutions to share information related to terrorism and money laundering. The EU's Anti-Money Laundering Directive permits information sharing for AML purposes. The UK's Joint Money Laundering Intelligence Taskforce (JMLIT) facilitates intelligence sharing between banks and law enforcement.
These programs are valuable but limited. They typically involve sharing specific information about known suspects rather than running analytics across the entire customer base. They require careful legal frameworks and often involve plaintext data sharing with associated breach risks.
FHE-based fraud detection goes further by enabling analytics across the entire encrypted customer base without any plaintext data sharing. This approach is more powerful than targeted information sharing because it can identify previously unknown fraud patterns, not just validate known suspects. And it is more compliant because no plaintext customer data crosses institutional boundaries.
Regulators are increasingly recognizing privacy-enhancing technologies as tools for compliant information sharing. The EU's Data Governance Act mentions FHE as an enabling technology. The UK's FCA has expressed support for privacy-preserving analytics in financial services. The US Treasury's innovation programs have funded research into encrypted fraud detection. H33's approach aligns with the regulatory trajectory: more information sharing, better privacy, and stronger compliance.
Performance at Scale
Cross-bank fraud detection must operate at the speed of transaction processing. A transaction approved in seconds cannot wait minutes for fraud screening. The fraud scores must be available before the transaction is completed, or the opportunity to prevent fraud is lost.
H33's production pipeline processes 2,293,766 encrypted operations per second at 38 microseconds per operation. For fraud detection, this means a consortium of ten banks, each contributing thousands of transactions per second, can have all transactions screened against cross-bank patterns in real time. The encrypted computation adds latency measured in microseconds, not seconds.
Batch processing is also supported for retrospective analysis. Banks can submit encrypted historical transaction data for pattern analysis, identifying fraud that was missed by real-time systems. The batch analysis runs at the same per-operation throughput, processing millions of historical transactions in minutes.
The consortium model scales linearly with the number of participating banks. Each additional bank adds encrypted data to the computation, increasing the total computation time proportionally. For consortiums of up to 20 banks, the per-transaction overhead remains within real-time processing requirements.
The Economics of Encrypted Consortium
The value proposition of cross-bank encrypted fraud detection is straightforward: catch fraud that individual banks miss. The incremental fraud prevented by cross-bank detection pays for the computation cost many times over. A single prevented fraud event worth hundreds of thousands of dollars justifies months of encrypted computation costs.
The cost structure is also advantageous. Each bank pays for its share of the encrypted computation, proportional to the volume of transactions it submits. There is no intermediary taking a margin on the data, because there is no data being shared. The computation cost is the only cost, and it decreases per transaction as the consortium grows because fixed infrastructure costs are amortized across more participants.
H33-Share handles the operational complexity of consortium management: onboarding new banks, managing encryption keys per institution, scheduling computation cycles, distributing encrypted results, and generating attestations. Banks interact with a clean API that abstracts the cryptographic complexity, submitting encrypted transactions and receiving encrypted fraud scores.
Cross-bank fraud detection without data sharing is not a theoretical possibility. It is a production-ready system running on ARM Graviton4 at 2,293,766 operations per second. The technology exists. The regulatory environment is favorable. The economic case is clear. The remaining question is not whether banks should do this but when they will start.
Implementation Roadmap
Deploying a cross-bank encrypted fraud detection consortium follows a phased approach. Phase one involves bilateral encrypted analysis between two banks, establishing the technical infrastructure and validating the fraud detection model on encrypted data. Phase two expands to a small consortium of three to five banks, testing multi-party key management and cross-institution coordination. Phase three scales to the full consortium, with automated onboarding, key management, and result distribution.
Each phase includes a validation step where the encrypted fraud detection results are compared against plaintext results (computed in a secure sandbox environment) to verify that the FHE computation produces identical fraud scores. This validation ensures that the encryption does not introduce false positives or false negatives into the fraud detection model.
The technical integration for each bank involves: deploying a client-side encryption module that converts transaction data into FHE ciphertexts, establishing a secure channel (TLS 1.3 + post-quantum key exchange) for ciphertext transmission, integrating the encrypted fraud scores into the bank's existing fraud investigation workflow, and configuring the H33-74 attestation verification in the bank's compliance reporting system.
H33 provides integration guides, client SDKs, and technical support for each phase. The typical timeline from initial engagement to production consortium operation is three to six months, depending on the participating banks' internal approval processes and integration complexity.
The economic model for the consortium distributes costs proportionally to transaction volume. Each bank pays for the encrypted computation of its own transactions, plus a proportional share of the shared infrastructure. The total cost is significantly less than each bank building its own fraud detection system, and the detection accuracy is significantly higher because of the cross-institutional visibility.