.png){kind=logo}
Quick overview
This is some text inside of a div block.
A compliance programme is only as available as the tools behind it. When a blockchain analytics provider goes offline, deposits and withdrawals keep settling, and sanctions screening, transaction monitoring, and Travel Rule obligations still apply to every transfer. A backup blockchain analytics provider is how compliance teams keep screening when their primary tool cannot.
The threat model behind that risk has changed. For a long time, attackers went after the obvious targets: asset holders, exchanges, and custodians. Recent incidents show that any player in the value chain can now be targeted, including the infrastructure providers compliance teams rely on every day, and some providers have had to take services offline to protect their data. A single vendor dependency can turn into an operational problem for the whole industry within hours.
This guide explains what breaks when screening stops, why vendor concentration risk is now a supervisory concern in every major jurisdiction, the three ways to run two providers, a seven-step plan to implement one, and what to look for in a second line of screening.
When a blockchain analytics provider goes offline, every control that depends on it stops at once: wallet screening at onboarding, Know Your Transaction (KYT) checks on deposits and withdrawals, sanctions screening, counterparty checks for the Travel Rule, and investigations. Transactions keep settling, so unscreened exposure grows with every block confirmed during the outage.
In practice, an outage removes five controls at the same moment:
Crypto markets do not close, so a screening outage forces an immediate choice. A firm can pause withdrawals and accept the customer and liquidity impact. It can keep processing and accept that transfers are leaving unscreened. Or it can fall back to manual review, which works for a handful of high-value transfers and breaks down at scale. The risk is concrete: without real-time monitoring, stolen funds can be accepted, swapped into other assets, and cashed out through the very channels meant to stop them. Whichever path a team takes, every hour of outage adds to the backlog it must screen retrospectively once service returns, and every unscreened transfer is a decision it may later have to explain to a supervisor.
Exchanges and custodians feel it in the withdrawal queue. Banks and payment service providers with crypto on-ramps and off-ramps feel it in delayed settlement and growing manual review. Stablecoin issuers and OTC desks lose the counterparty view they rely on for large transfers. Law enforcement and public agencies lose tracing capacity during live cases, where the first hours after a hack or ransomware payment often decide whether funds can still be frozen.
Relying on one blockchain analytics provider creates a single point of failure in controls that regulators treat as critical. If that provider is disrupted, breached, or changes its commercial terms, the firm loses screening capacity with no fallback, and it remains accountable to its supervisor for every transaction processed in the gap.
Vendor concentration risk is the exposure a firm takes on when a single third-party provider supports a critical function, or several functions at once, and cannot be replaced quickly. In crypto compliance, it usually arises when one blockchain analytics provider supplies all wallet screening, transaction monitoring, and investigation data.
Most business continuity plans picture a short technical outage. The realistic list is longer: a cyber incident that forces a provider to take products offline while it investigates, an infrastructure or data pipeline failure, a forced password reset that locks users out, a contract dispute or pricing change, or a sanctions or jurisdictional issue that restricts access to a provider in a given country. None of these is predictable. All of them are plausible over the life of a multi-year contract.
Blockchain analytics and transaction monitoring providers sit at a particularly sensitive point in the ecosystem: a regulated business cannot operate safely without them, which makes them attractive targets. With malicious AI agents now part of the threat model, attacks on infrastructure providers are likely to become faster and more automated. No provider can promise complete protection. What compliance teams should expect from a vendor is transparency during an incident and fast countermeasures to protect customer data, and taking a service offline to protect that data can be the responsible call. That is exactly why a firm needs a way to keep screening while its provider does the right thing.
Blockchain analytics is not a commodity. Each provider builds its own attribution data, its own entity labels, and its own risk logic, and coverage varies by blockchain and asset. The New York State Department of Financial Services (NYDFS) makes the same point in its guidance on blockchain analytics, noting that "the effectiveness of existing blockchain analytics tools can vary depending on the particular virtual currency in question" and that such tools "may have limited attribution capability." A second, independent dataset widens coverage across chains and gives investigators a second opinion on high-risk alerts, which is valuable even when nothing is down.
A firm with one deeply embedded provider has little leverage at renewal and a long road out if it needs to leave. Migration means re-integrating APIs, re-tuning risk thresholds, retraining analysts, and re-documenting controls for auditors. A firm that already runs a second provider has done most of that work in advance.
When a provider discloses a security incident that touches user data, the outage is rarely the end of it. Names, email addresses, and job titles of compliance staff are exactly what attackers need for targeted phishing: fake password-reset requests, spoofed "service restored" emails, and impersonated support calls. Compliance teams can reduce that exposure quickly:
Regulators in every major jurisdiction hold the firm, not its vendor, accountable for keeping critical services running. The common expectations are to identify critical third parties, assess how easily they could be replaced, keep documented contingency and exit plans, and test them. A screening outage is a business continuity event, and supervisors treat it as one.
The United Kingdom's Financial Conduct Authority (FCA) puts it plainly: if a third-party provider supporting an important business service fails to stay within impact tolerance, "the failure to remain within impact tolerance is your responsibility." Every framework below follows the same logic.
International standard-setters have set the direction for national rules:
European Union. The Digital Operational Resilience Act (DORA) has applied since January 17, 2025, and covers crypto-asset service providers (CASPs) authorised under the Markets in Crypto-Assets Regulation (MiCA). Before contracting, firms must assess whether an arrangement could reinforce ICT concentration risk, including whether a provider is "not easily substitutable." For ICT services supporting critical or important functions, exit strategies are mandatory, must be "sufficiently tested," and require firms to "identify alternative solutions and develop transition plans." Business continuity plans must be tested "at least yearly," including switchovers between primary infrastructure and redundant capacity. MiCA itself requires CASPs to "establish a business continuity policy" that includes ICT business continuity plans under DORA.
United Kingdom. The FCA's operational resilience rules have required full compliance since March 31, 2025. Firms must identify important business services, set impact tolerances for each, map the people, processes, technology, and third parties behind them, and include third parties in scenario testing.
United States. The interagency guidance on third-party relationships issued by the Federal Reserve, FDIC, and OCC in June 2023 asks banking organisations to outline contingency plans "in the event the banking organization needs to transition the activity to another third party or bring it in-house," and to assess options if a third party's ability to perform is impaired. For virtual currency businesses licensed in New York, the NYDFS guidance of April 28, 2022 allows firms to use third-party or internally developed blockchain analytics "whether separately or in combination," and requires clearly documented policies where those controls are outsourced.
Canada. The Office of the Superintendent of Financial Institutions (OSFI) Guideline B-10 asks federally regulated financial institutions to keep contingency plans for critical third-party arrangements and exit plans, for both stressed and non-stressed exits, that set out "alternative options or providers, supported by timelines, costs, resourcing, revenue impacts, and interim workarounds."
Singapore. The Monetary Authority of Singapore (MAS) Guidelines on Business Continuity Management, published in June 2022, require a service recovery time objective for each critical business service and flag the risk when several critical services are outsourced "to a single service provider." MAS cites "pre-designating an alternate service provider" as an example of a measure firms can take.
United Arab Emirates (Dubai). The Virtual Assets Regulatory Authority (VARA) Technology and Information Rulebook requires licensed VASPs to "implement, maintain, test and update on an annual basis" a business continuity and disaster recovery plan, and to notify VARA within 72 hours of an event that triggers it and materially affects operations. The same rulebook requires VASPs to "implement and maintain distributed ledger tracing software to screen incoming and outgoing Virtual Asset transactions," so in Dubai a tracing outage is a direct gap against a binding rule.
No framework reviewed here explicitly requires two blockchain analytics providers, but they all point in that direction. DORA states that firms "may" define a "holistic ICT multi-vendor strategy," MAS names an alternate service provider as a mitigation, OSFI asks exit plans to identify alternative providers, and VARA makes tracing software mandatory.
For most regulated firms, a tested second provider is the most direct way to evidence the continuity and exit planning their supervisor already expects.
Law enforcement agencies, financial intelligence units, and other public bodies are not supervised in the same way, but their dependency is just as real. Tracing during a live incident, such as an exchange hack or a ransomware payment, is time-critical, and a single-tool investigation unit loses those hours when its tool is unavailable. Investigators also benefit from cross-checking attribution between two independent datasets before acting on it.
A single provider is simpler to run and cheaper in the short term. A multi-vendor setup costs more to integrate and govern, but it removes the single point of failure, broadens coverage, and gives the firm a credible exit plan. The right balance depends on how critical screening is to the firm's operations.
High-volume exchanges and custodians, where every hour of outage means a growing withdrawal queue, are the natural candidates for active-active. Banks, payment service providers, and fintechs with crypto exposure usually find warm standby proportionate. Investigation-led teams and public agencies often start with a use-case split, because a second dataset improves case quality from day one.
Two providers only reduce risk if they do not fail for the same reason. If both run on the same cloud platform, the same hosting region, or similar infrastructure, a single incident can take both down at once. When choosing a second provider, compliance teams should ask how it is built and hosted, not only what it screens. Picking providers with different architectures is the simplest way to avoid shared points of failure, and it should sit alongside the other basics of resilience by design: solid backups, failover between providers, and load balancing, so that no single failure takes a critical service down.
Adding a second blockchain analytics provider follows the same path as any critical third-party change: map what depends on screening, choose an operating setup, integrate with automatic failover, align risk scoring, define how the team works during an outage, test the switchover, and document everything for supervisors and auditors.
The business case for a second blockchain analytics provider compares the cost of standby capacity with the cost of a screening gap. That gap includes halted or delayed withdrawals, manual review effort, retrospective screening backlogs, supervisory scrutiny, and reputational damage with customers and banking partners.
When presenting it to a CFO or board, compliance leads tend to find four arguments carry the most weight:
A backup blockchain analytics provider should be able to carry your critical screening on short notice, which means broad blockchain and asset coverage, independent attribution data, a fast and well-documented API, transparent risk scoring, strong security credentials, and data hosting in a jurisdiction your compliance and data protection teams accept.
Use this checklist when assessing candidates:
Scorechain is a European blockchain analytics and crypto compliance provider that has operated since 2015. Headquartered in Luxembourg, it runs on an EU-hosted private cloud and holds ISO/IEC 27001:2022 certification, which makes it suitable either as a primary provider or as an independent second line of screening.
Scorechain builds its own attribution data, so it adds a genuinely independent view rather than a duplicate of an existing provider. Today it covers 27+ blockchains, more than one billion labelled entities, and 2,800+ VASP due-diligence profiles, and it is used by 350+ compliance and digital asset teams.
For a second-provider setup, the relevant capabilities are:
Scorechain's ISO/IEC 27001:2022 certification, issued by Insight Assurance and valid until April 9, 2029, covers its SaaS platform, API, real-time transaction monitoring, risk scoring, and KYT capabilities. Alongside it, Scorechain aligns with DORA in Europe and runs regular penetration testing. Scorechain treats these as a baseline rather than an end point: continuous monitoring of every service is mandatory, and with malicious AI agents now part of the threat model, the team is actively evaluating how its defences need to evolve.
Scorechain's approach differs from many providers in the market: it runs on a private cloud with its own in-house infrastructure. That is not a claim to be better than the alternatives, only different. For compliance teams building a multi-provider setup, choosing providers built differently is a practical way to avoid sharing the same points of failure.
"Certifications and periodic tests are a baseline. Continuous monitoring of every service is mandatory. For customers who want several providers for redundancy, choosing ones built differently is a smart way to avoid sharing the same points of failure. This isn't about pointing fingers: every company is exposed, and the whole industry has to raise the bar together."
No regulation explicitly requires two providers, but regulators expect VASPs to keep tested continuity and exit plans for critical third parties. Because blockchain analytics supports sanctions screening, KYT, and Travel Rule compliance, a tested second provider is the most practical way for a VASP to show it can keep screening if its primary provider fails.
DORA allows, but does not require, a multi-vendor strategy: firms "may" define one. What DORA does require, for services supporting critical or important functions, is a concentration risk assessment, tested exit strategies, and identified alternative solutions. MAS, OSFI, and VARA set similar continuity expectations without mandating a second provider.
Vendor concentration risk is the exposure a firm faces when a single third-party provider supports a critical function, or several functions, and cannot be replaced quickly. In crypto compliance, it typically means relying on one blockchain analytics provider for all wallet screening, transaction monitoring, and investigation data.
Screen a shared sample of known addresses through both providers, then map their risk categories, exposure logic, and score scales against each other. Scales can run in opposite directions: Scorechain's runs from 0 to 100, where lower means higher risk. Set equivalent thresholds and document the mapping so auditors can follow every decision.
Onboarding time depends on three things: contract and security review, API integration with failover routing, and risk-score calibration. None of these should start during an outage. Firms that contract and integrate a second provider in advance, then complete a switchover test, can move critical screening across as soon as it is needed.
Yes, where possible. A second provider only removes the single point of failure if it does not share the primary provider's weaknesses. Providers running on the same cloud platform, hosting region, or similar infrastructure can be taken down by the same incident. Choosing providers with different architectures, combined with failover and load balancing, keeps critical screening running.
Continuity planning for critical third parties is expected under DORA and MiCA in the EU, the FCA's operational resilience rules in the UK, interagency guidance and NYDFS guidance in the United States, OSFI Guideline B-10 in Canada, MAS guidelines in Singapore, and VARA's Technology and Information Rulebook in Dubai.
Resilience is a compliance control. A second blockchain analytics provider, contracted, integrated, and tested in advance, turns a vendor outage from a crisis into a switchover, and gives your supervisor the evidence of continuity planning it already expects. No provider can promise complete protection, so resilience has to be shared: providers investing in security and transparency, and compliance teams building redundancy into their stack. The whole industry has to raise the bar together.
To see how Scorechain can work as your primary provider or as an independent second line of screening, book a demo.
.webp)
