Nine Questions to Ask Every On-Chain Risk Provider

Selecting a blockchain screening provider on the strength of a feature list is one of the more reliable ways to end up with a compliance gap you only discover during an incident. Elliptic's published framework identifies nine engineering decisions that separate providers in practice, and translates each one into a concrete question compliance teams, CFOs, and digital-asset auditors should put to any vendor before signing or renewing a contract. For firms running crypto accounting software alongside a separate AML screening layer, these questions are equally relevant when auditing the integration between the two.

Why Feature Lists Are the Wrong Starting Point

Every provider's sales deck describes coverage, speed, and configurability. What the deck rarely explains is the engineering choice underneath each capability, and those choices determine how the tool performs when it matters most. A provider whose screening relies on pre-computed, stored results behaves very differently from one that calculates exposure in real time, even if both describe themselves as "instant." The nine questions below are designed to surface those differences.

The compliance stakes

Regulators worldwide are explicit that transaction monitoring must be proportionate to risk and must actually work. A system that is technically live but returns stale data, goes offline during volume spikes, or cannot follow funds across blockchain boundaries is not meeting that standard, regardless of what the service level agreement says. For accounting firms and CFOs who must sign off on AML controls as part of financial statement preparation or regulatory filings, the quality of the underlying screening infrastructure is a material control question.

Question 1: Is the Exposure Calculated at the Moment of Screening?

A provider can compute risk at the moment a transaction is screened, or it can return a stored result calculated on a prior schedule. The difference is significant. Illicit funds move within seconds of a hack becoming known. New intelligence about addresses linked to the exploiter lands almost immediately. A real-time calculation incorporates that intelligence the moment screening is triggered. A stored result reflects the blockchain as it stood at the last calculation cycle, which may have been minutes or hours earlier.

What a suspicious answer sounds like

A response time measured in single-digit milliseconds is often a signal that the result was cached rather than computed. A genuine real-time screening takes slightly longer because it is doing real analytical work at query time. Providers should be able to explain which approach they use, and why, rather than simply citing a response-time figure.

Question 2: What Is Your Delivered Uptime, and Where Is It Published?

Every tenth of a percentage point of downtime translates to roughly nine hours a year without screening capability. A provider at 99% availability is inaccessible for more than ten days annually. Blockchains run continuously, and deposit flows do not pause because a vendor's system is down. Firms face a binary choice in that window: halt processing and take the operational hit, or continue without screening and accept a gap in controls. Neither is acceptable as a routine occurrence.

SLA versus delivered uptime

A service level agreement is a contractual floor. It tells you what a provider has committed to, not what it has actually delivered. Ask for a historical delivered uptime figure, how it is measured, and whether it is published in a format you can reference. Vague answers here are a due-diligence flag.

Question 3: Describe the Last Volume Spike You Absorbed

Cryptoasset transaction volumes do not grow smoothly. A liquidation cascade, a major exploit, or a token going viral can multiply transaction counts within minutes. That surge in volume typically arrives alongside a surge in risk, because market reactions and fund movements happen simultaneously. A provider that requires advance notice, manual provisioning, or a capacity conversation before absorbing a spike is, in practice, a provider with a ceiling on your operational resilience.

Latency under load

Staying online during a spike is necessary but not sufficient. A system that remains available but slows materially still disrupts screening workflows and can create backlogs that undermine the timeliness of your controls. Ask specifically whether response times held during the last major volume event, not just whether the system stayed up.

Question 4: What Does Full Coverage Actually Mean on Each Blockchain?

Blockchain coverage counts are not comparable across providers, because each provider defines coverage differently. Some count a chain as covered because addresses on it can be checked against a published sanctions list. Others count any chain that shares an address format with one they index. True operational coverage for AML purposes means transaction history is indexed, addresses carry entity labels, funds are followed across chain boundaries, and the chain is supported across every product in the suite.

Coverage tiers matter for your disclosures

When a firm tells a regulator or an auditor that a particular blockchain is covered by its monitoring controls, it is implicitly adopting its provider's definition. If that definition means sanctions-list-only rather than full entity-level screening, the firm's disclosure may be overstating its actual control. Ask providers to distinguish explicitly between full coverage and sanctions-only coverage for each chain they list.

Question 5: How Does Your Screening Handle Cross-Chain Fund Movements?

Funds move between blockchains constantly, via bridges, decentralised exchanges, and coinswap services. The blockchain record typically does not preserve the connection between the two sides of such a transfer. A screening that stops at a chain boundary still returns a result, but that result is limited to noting that funds passed through a bridge, which is not actionable intelligence. The trail ends exactly where the risk picture may be most relevant.

Automatic versus manual cross-chain tracing

Some providers require a manual workaround to follow a trail across chains, which introduces both delay and the possibility of human error. Ask to see a live demonstration of a screening following a fund trail across two or three blockchains automatically, and confirm whether that capability is available in the standard product or only in a premium tier. Understanding nine engineering decisions that define on-chain AML screening gives additional technical context for evaluating the answers you receive.

Question 6: If a Sanctioned Entity Creates a New Address Tomorrow, Will Your Screening Catch It?

When a regulator sanctions an entity, the designation typically includes a limited set of known cryptoasset addresses. Sanctioned entities control many more addresses and generate new ones continuously. A brand-new address from a sanctioned entity carries no transaction history. Screened in isolation, it returns clean. The only way to flag it is to link it to the entity behind it, which requires intelligence work rather than simple list-matching.

Cross-chain entity linkage

Linking an entity's addresses on a single blockchain is already non-trivial. Linking them across blockchains is harder still, because there is no on-chain relationship between, say, a Bitcoin address and an Ethereum address controlled by the same actor. Ask specifically how the provider constructs and maintains entity graphs across chains, and how quickly new addresses attributed to a known entity enter the screening dataset after attribution occurs.

Question 7: How Current and Granular Is the Intelligence Your Rules Are Applied To?

Configuration flexibility is a standard selling point. Every provider allows compliance teams to set risk rules, weight exposure categories, and define alert thresholds. But a sophisticated rule applied to coarse or stale underlying data produces a blurry output. A rule that distinguishes mixer exposure from gambling exposure only works if the provider has accurately labeled which addresses fall into each category in the first place.

Data currency and entity depth

Ask how frequently entity labels and exposure categories are updated, whether the intelligence extends to the entities behind addresses rather than only to officially listed ones, and whether that depth is consistent across all supported blockchains or concentrated on a handful of high-volume chains. This question connects directly to the quality of the alerts your digital asset accounting software and AML platform generate together.

Question 8: What Triggers an Alert When a Previously Cleared Wallet Becomes High-Risk?

A wallet assessed as clean at onboarding can become high-risk months later if new intelligence links addresses in its transaction history to illicit activity. Static, point-in-time screening does not catch that. Continuous monitoring does, but only if the alerting logic is intelligent enough to distinguish changes that actually move the risk score from changes that are technically new but analytically irrelevant.

Score recalculation versus raw change notification

An alert on every blockchain change produces a queue no compliance team can work through. The meaningful question is whether a detected change triggers a recalculation of the risk score using the firm's own rules, and whether the firm can configure which types of change are worth alerting on at all. Firms integrating AML screening with their crypto bookkeeping software should also confirm that recalculated scores flow through to the relevant ledger or reporting layer without manual intervention. Understanding how AI-enabled crime is reshaping AML best practices adds context for calibrating ongoing monitoring thresholds.

Question 9: Have You Tested a Full Regional Failover, and Can You Show the Results?

Cloud infrastructure is region-specific. Redundancy within a region protects against individual hardware failures and single data-centre outages. It does not protect against losing an entire cloud region, which happens. A firm's obligation to screen transactions does not pause because its provider's primary region is unavailable. Cross-region redundancy requires maintaining a second environment, replicating data to it continuously, and actually testing that the failover switch works and that results match what production would have returned.

Testing is the proof, not the architecture diagram

Any provider can describe a multi-region architecture. Ask when it was last tested end-to-end, how long recovery took, and whether the screening outputs in the failover environment matched production results. A provider that has never run a live failover test is carrying undisclosed operational risk, and that risk sits on your balance sheet if a regional outage coincides with a high-risk transaction window.

Accounting and Audit Implications

For accounting firms and CFOs, these nine questions are not only a procurement checklist. They map directly to control assertions that appear in financial statement audits, regulatory examinations, and internal risk assessments. A screening provider whose infrastructure fails any of these tests creates a potential control deficiency that auditors may need to note. Firms using digital asset accounting software that integrates with a screening layer should document how each of the nine dimensions is addressed and retained as evidence for audit purposes.

The quality of AML screening also affects transaction-level accounting decisions. A stale or incomplete screening result that clears a counterparty later found to be sanctioned can require transaction reversals, restatements, or regulatory disclosures, each of which has its own accounting treatment and timing implications. Building the due-diligence record now, before a provider relationship is formalised or renewed, is substantially cheaper than reconstructing it after the fact.

Practical Next Steps for Compliance and Finance Teams

Embed these nine questions in every RFP for AML screening services. Use them on first calls with new vendors and as a structured review agenda when renewing existing contracts. Request written answers where possible, and retain them as part of the vendor due-diligence file. Where a provider's answer is vague, ask for a live demonstration rather than accepting a narrative description. Cross-reference the provider's responses against publicly available information, such as published uptime dashboards or third-party audit reports, wherever those exist.

For firms operating across multiple jurisdictions, confirm that coverage, latency, and failover commitments apply globally and are not scoped to a specific region. Regulators in the EU, UK, US, and Singapore, among others, hold firms to the quality of their actual controls, not to what a vendor's contract promised.

Frequently Asked Questions

Why does real-time versus stored screening matter for compliance purposes?

Illicit funds can move within seconds of a hack or a new sanctions designation. A stored screening result reflects the blockchain as it stood at the last calculation cycle. If new intelligence about an address lands after that cycle but before your screening, your result is already out of date. Real-time calculation incorporates the latest intelligence at the moment of the query, which is what regulators expect when they require controls to be effective.

How should firms document their screening provider's capabilities for audit purposes?

Retain written answers to the nine questions above, plus any supporting materials such as uptime dashboards, architecture diagrams, and failover test results. Document the date of each review and store it in the vendor due-diligence file. Where the provider's answers are verbal, follow up in writing to create a record. This documentation supports the control assertions that auditors test during financial statement or regulatory audits.

What is the accounting implication of a screening gap caused by provider downtime?

If a transaction is processed during a downtime window without screening, and that transaction is later found to involve a sanctioned or high-risk counterparty, the firm may need to reverse the transaction, restate financial records, or make regulatory disclosures. Each of those outcomes has its own accounting treatment and timing requirements. Preventing the gap through robust provider selection is substantially less costly than managing the downstream accounting consequences.

Does cross-chain fund tracing affect how firms classify transactions in their books?

Yes, in some cases. If a screening provider cannot follow funds across a bridge and the trail ends at the chain boundary, the firm lacks visibility into the ultimate source or destination of value. For accounting purposes, transactions with opaque provenance may require different classification or additional disclosure, particularly where the firm has a policy of not accepting funds from high-risk sources. Accurate cross-chain tracing reduces the population of transactions that require manual review and reclassification.

How often should firms re-evaluate their AML screening provider against these criteria?

At minimum, at each contract renewal and whenever a material change occurs, such as adding a new blockchain to the firm's accepted asset list, expanding into a new jurisdiction, or a significant incident at the provider. Many firms schedule an annual vendor review as part of their broader compliance calendar. The nine questions above provide a consistent framework for that review regardless of how frequently it is conducted.

Source: Elliptic