How Banks Can Validate Without Seeing Data

There is a belief embedded so deeply in financial services that it is rarely stated, let alone questioned: to validate something, you must see it. To screen a name against a sanctions list, you must read the name. To match a beneficiary to an account, you must see the account details. To assess risk, you must see the risk attributes. To verify identity, you must see the identity.

This belief is wrong. Not approximately wrong or theoretically wrong. Mathematically wrong. Fully homomorphic encryption allows computation on encrypted data — the same computations, producing the same results — without ever decrypting it. The data remains encrypted throughout the entire operation. The result is encrypted. Only the party holding the decryption key can read the output. The party performing the computation learns nothing about the input or the output.

This is not a privacy enhancement. It is not a data masking technique. It is not tokenization with a reversible mapping. It is a mathematical guarantee that the computation was performed correctly on data that was never accessible to the computing party. The impossibility of access is not operational — enforced by policies, controls, and contracts. It is mathematical — enforced by the hardness of lattice problems that no known algorithm, classical or quantum, can solve efficiently.

The Five Validations

Banking compliance involves dozens of validation operations, but five account for the overwhelming majority of data exposure: sanctions screening, beneficiary matching, jurisdiction checks, risk scoring, and identity verification. Each of these traditionally requires plaintext access to sensitive data. Each can now be performed on encrypted data with no loss of accuracy or completeness.

Sanctions Screening on Encrypted Names

Sanctions screening is the most frequently cited reason why compliance systems need raw data access. The argument is simple and, on its surface, compelling: to compare a customer name against a sanctions list, you must be able to read the name and compare it character by character against the list entries. Fuzzy matching algorithms — Jaro-Winkler, Levenshtein, Soundex — all operate on plaintext strings.

FHE-based sanctions screening replaces plaintext string comparison with encrypted string comparison. The customer name is encrypted. The sanctions list entries are encrypted. The comparison algorithm operates on the ciphertexts using homomorphic operations that mirror the plaintext operations: character-by-character comparison, edit distance calculation, phonetic encoding and matching. The output is an encrypted similarity score. If the score exceeds the configured threshold, the output is an encrypted match flag.

The screening entity — whether it is an internal compliance system, an external vendor, or a correspondent bank — never sees the customer name or the match result. It performs the computation on encrypted data and produces an encrypted output. The originating bank decrypts the output and acts on it: clear the transaction, flag it for review, or block it.

The accuracy of FHE-based sanctions screening is identical to plaintext screening. This is not an approximation or a statistical guarantee. It is a mathematical property of fully homomorphic encryption: the decrypted output of a homomorphic computation is exactly equal to the result of performing the same computation on the plaintext inputs. If the plaintext screening would have flagged a name, the encrypted screening flags it. If the plaintext screening would have cleared it, the encrypted screening clears it. The results are identical because the mathematics guarantee it.

Beneficiary Matching on Encrypted Accounts

Beneficiary matching — verifying that the beneficiary name and account number in a payment instruction correspond to a valid account at the receiving institution — is another operation that traditionally requires plaintext access. The receiving bank compares the incoming name and account number against its customer database. If they match, the payment is credited. If they do not, the payment is flagged for investigation or returned.

Encrypted beneficiary matching works as follows. The originating bank encrypts the beneficiary name and account number using the receiving bank's FHE public key. The encrypted values are transmitted with the payment instruction. The receiving bank's matching system compares the encrypted values against encrypted versions of its customer records. The comparison produces an encrypted match/no-match result, which the receiving bank decrypts.

The key distinction: the originating bank's encrypted data is compared against the receiving bank's data without either bank seeing the other's records in plaintext. The originating bank does not learn which specific account the beneficiary holds (beyond confirming it exists). The receiving bank does not see the originating bank's internal beneficiary record format. The matching happens in the encrypted domain. Both parties learn only the binary result: match or no match.

This protects both institutions. The originating bank's customer data stays encrypted outside its perimeter. The receiving bank's customer database is never exposed to external queries on plaintext values. The matching is as accurate as plaintext matching — because, again, the homomorphic computation produces mathematically identical results.

Jurisdiction Checks on Encrypted Locations

Jurisdiction checks determine whether a transaction involves parties, accounts, or activities in sanctioned, restricted, or high-risk jurisdictions. These checks typically require plaintext access to country codes, postal codes, addresses, and business registration jurisdictions — data that directly identifies the location of the parties involved.

Encrypted jurisdiction checks operate on encrypted location data. The country code is encrypted. The postal code is encrypted. The address fields are encrypted. The FHE processing pipeline compares these encrypted values against encrypted jurisdiction classifications — sanctioned country lists, high-risk jurisdiction registers, restricted territory databases — and produces encrypted results indicating the jurisdiction risk level for each party.

The processing entity sees none of the location data. It does not know which country is being checked. It does not know whether the result is high-risk or low-risk. It performs the computation on ciphertexts and produces a ciphertext output. The originating bank decrypts the result and applies its jurisdiction risk policy.

For correspondent banks that perform jurisdiction checks on wire traffic, this is particularly valuable. A correspondent bank processing thousands of wires daily currently maintains plaintext records of every transaction's geographic footprint — which countries are involved, which corridors are active, which parties are located where. This geographic data is extraordinarily sensitive and extraordinarily attractive to threat actors conducting economic espionage. Encrypted jurisdiction checks eliminate this exposure entirely. The correspondent performs the checks. It never sees the geography.

Risk Scoring on Encrypted Attributes

Risk scoring models in banking compliance evaluate transactions and relationships across multiple dimensions: transaction amount, frequency, corridor, customer profile, counterparty profile, historical patterns, and dozens of other attributes. Traditional risk scoring requires plaintext access to all of these attributes because the scoring models — whether rule-based, statistical, or machine-learning-derived — operate on numerical and categorical values that must be readable.

FHE-based risk scoring operates on encrypted attributes. The transaction amount is encrypted. The frequency count is encrypted. The corridor classification is encrypted. The customer risk profile is encrypted. The scoring model is applied to these encrypted values using homomorphic operations: addition, multiplication, comparison — the fundamental operations that underlie every risk scoring model from simple rule-based systems to complex neural networks.

The encrypted risk score is produced as a ciphertext. The originating bank decrypts it to obtain the numerical score and applies its risk appetite thresholds. The entity that performed the scoring — whether an internal system, an external vendor, or a utility — never sees the attributes or the score. It knows that a scoring computation was performed. It does not know on what data, and it does not know the result.

This capability has significant implications for compliance vendor relationships. Banks currently share detailed transaction and customer attributes with risk scoring vendors. These vendors build models on aggregated data from multiple banks — which provides model quality benefits but creates massive data concentration risk. A breach at a major compliance vendor could expose transaction-level data from dozens of banks simultaneously. Encrypted risk scoring preserves the model quality — the vendor's model is still applied to real data — while eliminating the data concentration risk. The vendor never possesses the data. It possesses the model, and the model operates on ciphertexts.

Identity Verification on Encrypted Credentials

Identity verification — confirming that a person is who they claim to be — is the most sensitive validation in banking. It involves biometric data, government-issued identity documents, personal information, and authentication credentials. Traditional identity verification requires all of this data to be plaintext-accessible at the verification point.

H33's biometric verification pipeline performs identity matching on encrypted biometric templates. A customer's biometric data — fingerprint, face, voice — is captured, encoded as a numerical template, and encrypted. The encrypted template is compared against an encrypted enrolled template using homomorphic inner-product computation. The result is an encrypted similarity score. If the score exceeds the verification threshold, the identity is confirmed.

The verification system never sees the biometric data. It never sees the enrolled template. It never sees the similarity score. It performs a mathematical operation on two encrypted vectors and produces an encrypted scalar. The institution that holds the decryption key — the bank that enrolled the customer — decrypts the result and makes the authentication decision.

This is critical for banking because biometric data is uniquely sensitive. Unlike passwords, biometric data cannot be changed if compromised. A stolen fingerprint template is a permanent identity compromise. FHE-based biometric verification eliminates the possibility of template theft at the verification point because the template is never plaintext at the verification point. It is encrypted from the moment it leaves the capture device until the moment the result is decrypted by the key holder.

The Proof Layer

Performing validation on encrypted data solves the data exposure problem. But it creates a new question: how does a third party — a regulator, an auditor, a counterparty — know that the validation was actually performed, and performed correctly?

This is where the proof layer operates. Every encrypted validation in H33's pipeline produces a cryptographic proof alongside the encrypted result. The proof attests that a specific computation was performed on specific encrypted inputs, using a specific algorithm, at a specific time, and that the encrypted output is the authentic result of that computation.

The proof does not reveal the inputs, the outputs, or any intermediate values. It reveals only that the computation happened and that it happened correctly. A regulator verifying the proof learns that sanctions screening was performed using a specific algorithm against a specific list version at a specific timestamp. The regulator does not learn the customer's name, the screening result, or any other detail beyond the fact of correct execution.

If the regulator needs the underlying details — for an investigation, under proper legal authority — it requests them from the institution that holds the decryption key. The proof provides the foundation: it identifies exactly which computation was performed, which allows the regulator to request the specific decrypted results it needs rather than conducting a broad fishing expedition through the institution's records.

Every proof is attested by H33-74. The 74-byte attestation uses three post-quantum signature families based on three independent hardness assumptions. The attestation is timestamped, chained to previous attestations in a hash chain, and independently verifiable. The proof remains valid for the full regulatory retention period — including through the quantum computing transition — because the signatures are quantum-resistant by construction.

Performance: Milliseconds, Not Minutes

The historical objection to FHE in financial services has been performance. Early FHE implementations were orders of magnitude slower than plaintext processing, making them impractical for real-time compliance operations. This objection is obsolete.

H33's FHE pipeline processes compliance operations in milliseconds. Sanctions screening on an encrypted name completes in single-digit milliseconds. Beneficiary matching on encrypted accounts completes in comparable time. Risk scoring on encrypted attributes runs in the same order. The per-operation latency is well within the processing windows of real-time payment systems, wire transfer platforms, and trade settlement engines.

The performance is achieved through engineering optimizations specific to the compliance use case. Financial compliance operations are structured computations — comparisons, lookups, scoring functions — that map efficiently onto FHE's supported operations (addition, multiplication, rotation). The key sizes, encryption parameters, and computation strategies are tuned for these specific operation types, not for general-purpose computation. The result is a pipeline that is fast enough for production compliance workloads while maintaining the full mathematical guarantees of FHE.

Batch processing further improves throughput. Multiple transactions can be processed simultaneously within a single FHE computation, amortizing the encryption and decryption overhead across the batch. For high-volume wire processing — where hundreds or thousands of transactions flow per second — batch FHE processing achieves throughput levels that exceed the requirements of every major payment network.

This Is Not Masking

It is important to distinguish encrypted validation from data masking. Masking replaces sensitive values with non-sensitive substitutes — asterisks, partial values, randomized characters — for display or transmission purposes. Masking is a presentation-layer control. The underlying data exists in plaintext somewhere in the system. The mask can be removed by anyone with appropriate access. Masking reduces casual exposure but does not prevent determined access.

FHE encryption is not masking. The data does not exist in plaintext in the computing system. There is no "unmasking" operation because there is nothing to unmask — the data was never plaintext in the first place. The decryption key exists only at the originating institution. Without that key, the encrypted data is computationally indistinguishable from random noise. This is not a security policy that can be overridden by an administrator. It is a mathematical property of the encryption scheme.

The distinction matters operationally. A masked system can be breached by compromising the masking/unmasking infrastructure. An FHE system can only be breached by obtaining the decryption key — which never leaves the originating institution's hardware security module. The attack surface is fundamentally different: institutional infrastructure versus a single cryptographic secret held in tamper-resistant hardware.

The Regulatory Alignment

Regulators worldwide are moving toward data minimization as a core principle. GDPR's data minimization principle (Article 5(1)(c)) requires that personal data be "adequate, relevant and limited to what is necessary." The CCPA grants consumers the right to know what data is collected and shared. FATF guidance increasingly acknowledges that technological solutions can satisfy compliance requirements without traditional data-sharing patterns.

Encrypted validation is the technical realization of data minimization in compliance. The data necessary for the computation is present — in encrypted form. The data is adequate for the compliance check — because FHE produces mathematically identical results. The data shared externally is limited to what is necessary — the proof of compliance, not the underlying personal data. Every regulatory principle around data minimization is not just satisfied but technically enforced.

The Fundamental Shift

For decades, validation and data access have been synonymous in banking. To validate was to see. To screen was to read. To score was to analyze plaintext attributes. This synonymy was not a design choice — it was a technological limitation. The mathematics to compute on encrypted data did not exist, and then they did exist but were too slow, and then they were fast enough but not proven in financial applications.

Those barriers are gone. H33-Wire-Proof processes encrypted compliance operations at the speed financial services demands, with the accuracy financial regulations require, and with the proof infrastructure financial auditors and regulators need. The result is provable. The data was never readable. This is not an incremental improvement to existing compliance architecture. It is the elimination of the core assumption — that validation requires data access — on which the entire compliance data-sharing model was built.

Banks can validate without seeing. The proof is verifiable. The data is protected by mathematical impossibility, not operational policy. The compliance outcome is identical. The data exposure is zero. That is the shift. It is not coming. It is here.