Two questions come up on almost every enterprise diligence call for wallet and custody providers: "How do you screen counterparties?" and "Can my clients see what you saw?" The first question has been answered the same way for years: a risk score from a blockchain analytics vendor. The second question is where most providers fall short, and where the competitive gap is opening.
Institutional wallet customers (hedge funds, family offices, corporate treasuries, increasingly banks) have compliance programs of their own. When they use a custodial wallet, they need that wallet's screening to plug into their own evidence requirements. A risk score returned through a vendor dashboard is not evidence. It is a conclusion without a source.
Why a risk score is no longer enough
The regulatory standard for defensible compliance output has shifted. Three years ago, a wallet provider could point to a risk score from a recognized vendor and satisfy most counterparties. Today, examiners and institutional clients want the underlying attribution: which entity was identified, through what evidence, at what confidence level, at what timestamp.
FinCEN's framework on blockchain analytics and the EU's AML supervisory expectations both emphasize explainable outputs, not opaque scores. Institutional buyers reinforce this. They have been burned by cases where a score was wrong and no audit trail existed to explain why.
A wallet provider whose compliance output is a single number cannot answer the question "how did you reach that conclusion?" That answer is increasingly disqualifying for enterprise relationships.
The two compliance layers wallet customers need
Institutional wallet customers need compliance support at two levels. The first is operational: real-time counterparty screening on every transaction, automated alerts when risk profiles change, and a clean interface for the compliance team to review flags and close cases. This is the back-office layer. It keeps the AML program running and produces the records a regulator would review.
The second level is customer-facing: the ability to show their own clients what was screened, how the risk was assessed, and what the evidence was. A family office managing assets for multiple principals needs to demonstrate to each principal that counterparty risk is managed. A fintech building payments on custody infrastructure needs to expose compliance status in its own product without routing every question through a third-party portal.
These two needs are architecturally distinct. The back-office layer requires high throughput, low latency, and deep case management. The customer-facing layer requires white-labeled evidence output: attribution and reasoning the wallet can embed in its own UI rather than pointing customers to a vendor dashboard.
Privacy is not a secondary concern
Every time a wallet screens a counterparty address, it reveals something about its own customers. The transaction graph is a map of who traded with whom, at what size, at what time. Most incumbent screening vendors ingest that full transaction context by default.
That matters to enterprise buyers in two ways. First, their security and legal teams review vendor data agreements. A screener that harvests full transaction graphs to train its own models fails that review. Second, a wallet's biggest institutional clients are exactly the clients who will surface this question first. These are the same clients who drove them to seek enterprise contracts.
Counterparty-only screening is the architectural answer. The wallet screens the address on the other side of the transaction. It does not send its own customer's transaction history or wallet balances. The data the vendor receives is the counterparty identifier and a timestamp. Nothing else.
The SR³ Intelligence Layer is built around this model. Each screening call passes the counterparty address. The response returns risk level, entity attribution, confidence, and reasoning chain. The wallet's own transaction graph stays on the wallet's infrastructure. This is the answer that passes a security questionnaire.
MSB licensing and the debanking risk
Wallet providers that operate as money services businesses face a specific compliance pressure consumer fintech companies often underestimate. MSB licensing requires AML program documentation that banking partners review regularly.
A wallet provider's banking relationship is the operational backbone of their business. Losing it because a compliance examiner found the AML program inadequate is not hypothetical. It has happened to multiple providers in the past three years. The common thread: not bad actors on the platform, but inadequate documentation of how counterparty risk was managed.
Banking partners want to see the screening program in concrete terms. What gets screened, against what data, with what thresholds, and what happens when something is flagged. They want case records showing alerts were reviewed and resolved. They want to see that the program is calibrated for the wallet's actual transaction profile.
The wallet provider that can walk a banking partner through their compliance program in detail retains the relationship. Here is the screening API. Here are the risk models. Here is how a flagged transaction gets escalated. Here is a sample evidence package. The one that answers "we use vendor]" and cannot go deeper does not.
Embedding compliance in the product
The providers winning enterprise wallet relationships treat compliance as a product surface. That means giving customers visibility into what was screened and why. It means exposing attribution data through APIs customers can integrate into their own reporting and audit workflows.
Concretely, this looks like three things. An API endpoint that returns not just a risk level but the entity attribution behind it, with source provenance the customer can cite in their own compliance records. A webhook that notifies the customer's system when a counterparty's risk profile changes, with enough detail to trigger their own review process. A reporting endpoint that produces the periodic summary the compliance team needs for program documentation.
The SR³ Intelligence Layer ships every screening result with full reasoning and source attribution. The same data structure that powers the provider's own compliance review also powers the evidence the provider can expose to customers. One system, multiple surfaces.
This is also where compliance becomes a revenue line rather than a cost line. Wallet providers that expose attribution-quality evidence to their clients can charge for that visibility. Enterprise customers pay for the ability to close their own compliance loops without depending on a vendor portal. That pricing conversation is easier when the product can show the evidence, not just claim it exists.
Developer experience: what "a sprint" actually means
The compliance infrastructure that supports enterprise wallet relationships needs to integrate cleanly with the wallet's existing stack. A REST API with predictable latency and documented error behavior, not a portal-first product that had an API bolted on after launch.
The concrete integration surface for counterparty screening is narrow. Four endpoints cover the core use case: screen an address, retrieve a cached result, fetch full attribution for a flagged address, and pull a periodic summary for a date range. Latency on the screen endpoint runs under 10ms for single-address lookups and about 100ms for large batches. That is fast enough to sit in the deposit hot path without adding user-visible delay.
Webhooks handle the asynchronous surface: risk profile changes, new entity attributions, sanctions hits. The webhook payload carries the same attribution fields as the synchronous response, so the same handler processes both paths.
Error surfaces are documented and deterministic. A 429 means rate limit with a retry-after header. A 404 on an address means no attribution data exists, not a system error. The compliance team's case queue can ingest failures as pending reviews rather than crashing on unexpected responses.
An engineering team that has integrated one external API before can complete the core integration in a week. The webhook handler and case queue wiring typically add another few days. No dedicated FTE required.
The integration question
At scale, manual reconciliation fails. A portal-first product requires the compliance team to operate a separate system, log into a separate UI, and manually reconcile records. That model breaks when transaction volume grows or when the compliance team is two people covering multiple product lines.
The providers who have shipped compliance as a product feature have done it by choosing infrastructure that treats the API as the primary interface. The dashboard is a view into the same data. The evidence package is generated from the same attribution graph. The customer-facing output is the same record the provider's own compliance team reviews.
That architecture is what lets a wallet provider answer "can my clients see what you saw?" with yes, without building a separate system to make it true.