The New Compliance Building Block

Every company that touches money performs the same ritual with its customers. It asks for information, the customer provides information, the company verifies the information. The choreography may differ from company to company, but it is essentially the same dance.

This is not to dismiss the purpose of this information exchange: Financial institutions have obligations to their regulators, their partners and their customer base to ensure that they are only letting safe, secure customers onto their rails. These exchanges are designed to reduce risk, and they do.

However, this approach to managing sanctions screening, financial crime checks and anti-fraud measures overlooks two other dimensions of risk to both the company and the customer: Financial institutions carry the liability for the pile of customer data that is ingested throughout the onboarding process. The customer’s risk is greater. Every customer that onboards with a new financial institution must share that same set of data with each successive company where they open an account, compounding their data exposure across multiple entities.

There is a different way to build this. A compliance check can live on a shared network as an audited building block, called a “policy.” Any institution on the network can rely on a policy, while the customer’s personal data never touches the network.

Two Kinds of Safety

Under a policy, the customer's personal information stays in one place. Because a shared network keeps a permanent record, personal data never goes onto it. Instead, a “zero-knowledge proof” (“ZKP”) crosses the network. A ZKP is a way to show that a statement about the customer is true without revealing the information behind it. You can prove that you are eighteen without turning over your driver’s license. A business can attest to its financial health without turning over bank statements. The financial institution onboarding the customer can get the information that it needs via the ZKP while the customer’s underlying data remains confidential.

The second dimension of safety is in the code. When a hundred firms each write their own screening logic, there are a hundred separate places a mistake can hide, and each one is reviewed only by the team that wrote it. Consolidate onto one shared policy and there is a single, small surface to check, watched by everyone who depends on it. A smaller surface means fewer places for an exploit to live. Trust is derived from having many eyes on a single element, which is the reverse of how compliance code usually works. The tradeoff is that a flaw in a shared policy would affect everyone who relies on it, which is why audit and open review matter more here.

Easy to Adopt, Easy to Explain

A shared check is only useful if the financial institution using it can understand the concept well enough to explain it to a regulator or another invested party. A policy is built for exactly that. If a widely used policy already covers a requirement, an institution can use it instead of writing its own. Onboarding becomes a matter of choosing the right policy for the product and the market, the way a developer today reaches for a well-tested library instead of writing encryption from scratch.

And because the check is already built, the adopting team needs to understand what it proves, not how the cryptography achieves it. The math behind these proofs is genuinely hard to get right, which would normally keep it out of reach for most engineering teams. A policy puts that difficulty underneath the surface, already built and already audited. The institution picks the policy that fits and integrates it.

Reuse That Compounds

A shared check is safer and easier to adopt even if only one institution uses it. Reuse is the third benefit, and it is where the advantages start to compound.

Policies are shared, but they can also be combined. A service assembles its precise requirements from checks that already exist. As more institutions lean on the same checks, the useful ones attract adoption, and adoption attracts scrutiny. The most-used policies become the defaults, for the same reason old standards earned trust. They have survived scrutiny over time.

The compounding reaches the customer too. Where the rules allow one institution to rely on another’s verification, someone verified once can satisfy the same requirement at the next service without handing over their information again. Their verified status can travel with them across services on the network. The customer meets less repeated friction, and the business inherits a larger pool of already-verifiable customers and a smaller pile of data to guard.

A Closer Look at a Policy

A policy is an audited compliance check published at a fixed address on the network, which any institution can find and rely on. It checks zero-knowledge proofs, and it works because getting verified and proving it are two separate steps.

‍

First, the customer is verified once, through the same kind of identity checks that we recognize today. The provider that verifies the customer issues a credential, a signed record of the information that was confirmed, which the customer keeps. The credential carries the actual personal data, so it stays with the customer and never touches the network.

From then on, proving it is a matter of using that credential. When a service needs to confirm that a customer qualifies, a proof is generated from the credential, either on the customer’s own device or by the provider on their behalf, showing that they satisfy the policy without exposing anything inside it. The service reads back a simple “yes” or “no.” The customer controls when their credential is used, and the service never builds or maintains the check itself. Published once, a policy can be reused by any institution on the network.

Onboarding Turns from a Build to an Integration

Imagine a fintech onboarding a new customer. Before letting that customer hold or move funds, the fintech has to confirm that the customer is verified, lives in an eligible market, and clears sanctions checks.

The “traditional” version is heavy. The company collects a customer's identity documents, stores them, and builds its own process to screen against sanctions lists and eligibility rules. The same customer has to repeat the process for each account that they open.  Each company where the customer opens an account holds personal data that becomes its responsibility. The check is undifferentiated, and the burden sits entirely with each company.

A policy changes that: An audited policy covering all three requirements is already published on the network. The customer is verified just once and then holds a credential. When the fintech requests it, a proof is generated from that credential, on the customer’s device or by their provider. In a well-designed policy, sanctions screening runs continuously, and the policy is updated when a list changes, so the check reflects current lists.

The fintech receives the confirmation it needs. The verifying provider retains the underlying records, and the fintech can retrieve them for an examiner or audit when required. Documents don’t need to pass between institutions day to day, nothing sensitive is written to the network, and the fintech relies on the same check that other institutions on the network use and inspect. Onboarding turns from a build into an integration.

Compliance Becomes Infrastructure

Compliance is one of the most important functions in financial services, and one of the most duplicated. Every team rebuilds the same checks, which absorbs engineering time, concentrates risk, and spreads sensitive data across more systems than anyone would choose. Handling the check as a shared, audited building block changes the shape of the problem. A policy is written and reviewed once, reused widely, and run without ever putting the customer's data on the network. Each institution still owns its compliance program and answers to its regulators. A shared policy changes how the check is built and reviewed, while accountability stays with the institutions.

This is a foundation that a payments-first network can lay from the start. And it improves with use. Every institution that relies on a shared policy adds to the scrutiny behind it, which makes the next one safer to build on. Compliance stops being something each company builds alone and becomes shared infrastructure that gets stronger with every institution that relies on it.