Every time a wallet provider screens a counterparty address, they face a choice most don't realize they're making. Sending the full transaction context (the customer's address, the counterparty, the amount, the chain) to a third-party API produces a risk score. It also produces a detailed map of your customers' transaction behavior, sitting in a vendor's cloud database.
For consumer wallets handling low-value transfers, this may be an acceptable trade. For institutional wallets serving hedge funds, family offices, and banks, it is a dealbreaker that surfaces in every security questionnaire.
This is also a product problem, not just a compliance problem. The wallet providers winning institutional mandates today treat compliance as a customer-facing feature. Their clients see attribution evidence. Their engineers ship integrations in days. Their compliance posture becomes a sales argument, not a diligence hurdle.
The transaction harvesting problem
Blockchain analytics vendors built their business on data aggregation. The more transaction data they ingest, the better their attribution models become. When a wallet provider calls their screening API with a full transaction payload, they are contributing to that aggregation. Their customer's counterparty data becomes part of the vendor's training set.
The practical consequences are not hypothetical. An institutional client whose transaction patterns are visible to a vendor's entire customer base has lost competitive intelligence. A family office whose counterparty relationships are logged in a third-party database has a data residency problem. A bank whose custody clients' transactions are processed in a vendor cloud may have a regulatory problem depending on jurisdiction.
The response from most vendors is that data is anonymized or aggregated. That answer doesn't satisfy a legal team doing a SOC 2 review or a security officer answering a fund's diligence questionnaire.
What address-only screening changes
The architectural alternative is to screen the counterparty address only. You don't send the customer's address, the transaction amount, or any context that identifies whose transaction is being screened.
This sounds like a minor change. It is structurally significant. The screening call becomes: "what is the risk profile of this address?" rather than "what is the risk of this transaction from this customer to this counterparty?" The vendor receives no information about who is transacting or how much. The customer's transaction graph stays on the wallet provider's infrastructure.
The trade-off is that some risk signals are context-dependent. A small transfer to a flagged address may carry different weight than a large one. Address-only screening gives up that context in exchange for a privacy posture that survives security review. For most wallet compliance workflows, the trade is worth making.
Latency and the hot path problem
Compliance screening is in the hot path of every deposit and withdrawal. A screening call that adds 500ms to a transaction confirmation is a product problem before it is a compliance problem. At institutional scale, it is also an operational problem. A vendor outage that returns errors or timeouts forces the wallet to either block all transactions or bypass screening. Neither is acceptable.
Sub-10ms screening latency is achievable. The pattern: a local label cache handles the majority of queries without any network call. A remote call fires only for addresses not in cache. A circuit breaker fails open to a conservative risk posture rather than blocking all transactions when the remote is unavailable.
The SR³ screening layer ships this pattern as a default. The API surface is a single POST to /screen with an address and chain parameter. The response includes a risk score, a source label, and a confidence tier. Error handling returns a structured object with a degraded flag rather than a 5xx, so the wallet can apply its fallback policy without guessing. An SDK is available in TypeScript and Python. A team that has read the docs can have a working integration in a day.
Uptime SLAs matter here in a way they don't for off-path tools. A 99.9% uptime SLA means roughly 8 hours of downtime per year. For a custody platform processing institutional transactions around the clock, that is 8 hours of either blocked withdrawals or unscreened transactions.
Private labels and data sovereignty
Over time, a wallet's compliance team accumulates intelligence that is specific to their customer base. Addresses they identified through their own investigations. Entities they labeled through direct KYB. Relationships they traced manually. This is proprietary intelligence.
Storing that intelligence in a vendor's shared database means it can be inferred by other customers of the same vendor, or lost when the vendor relationship ends. Wallet providers that take this seriously keep their private labels in their own infrastructure, queried locally at screen time, never exposed to any external system.
The right architecture separates two things. Public label data is the vendor-maintained database of exchanges, mixers, and sanctioned entities. Private label data lives on the wallet provider's own systems. At query time, the two merge into a single risk score. The SR³ screening layer is built around this separation: public attribution from the shared intelligence layer, private labels from the customer's own store, combined at query time. Private data never leaves the customer's infrastructure.
What your customers can see
The security questionnaire is the minimum bar. The wallet providers gaining ground with institutional clients go further: they expose compliance evidence to their own customers in their own UI.
An institutional client that sees a withdrawal blocked wants to know why. "Your counterparty address is flagged" is not enough. They want the source of the flag, the entity name, the risk category, and the confidence score. They want that information in your interface, not in a third-party vendor portal they don't have a contract with.
The Strix attribution API returns structured evidence alongside the risk score: entity name, category, source database, first-seen date, and a machine-readable path. Your frontend team can render this in your own UI using the response directly. You can white-label it. You can scope it per customer tier. You can use it to justify a compliance feature line item in your pricing. A wallet provider charging $200/month for a "compliance dashboard" add-on is not unusual once the evidence layer is exposed.
This is the gap most wallet compliance stacks leave open. They return a score. They don't return the reasoning. Clients who want the reasoning go elsewhere or build their own.
What survives a security questionnaire
When an institutional client's security team reviews a wallet provider's compliance infrastructure, they ask a short list of questions. Does the provider send full transaction data to third parties? Where is customer transaction data stored? What happens to screening data after the call completes? Who has access to the provider's attribution data?
The wallet providers that answer these questions cleanly have made deliberate architectural choices: counterparty-only screening, no persistent transaction logs on vendor systems, private label data on their own infrastructure. Those choices are visible in the API design and the data flow documentation. They are not something that can be added retroactively to a system built on full-transaction APIs.
Building for the security questionnaire from the start is cheaper than retrofitting after the first enterprise client asks. It is also cheaper than losing that client to a competitor who already has the answers ready.