Reliability engineering at Scorechain, the six commitments behind our uptime

The crypto threat landscape has changed, and nobody in theecosystem is out of scope anymore. For years the targets were obvious: assetholders, exchanges, and custodians. Today, any player in the value chain can be targeted, including the infrastructure providers compliance teams depend on every day.

Blockchain analytics sits at a particularly sensitive point in that chain. A regulated business cannot operate safely without real-time screening, which makes the reliability of its analytics provider a compliance question, not only an engineering one. This article sets out how Scorechain approaches it: our measured uptime over the last 12 months, what the numbers mean in practice, the principles behind them, and how compliance teams can assess any provider's reliability claims.

Why is reliability part of compliance?

Reliability is part of compliance because screening obligations never pause. Transfers settle 24/7, and sanctions screening, Know Your Transaction (KYT) checks, and Travel Rule counterparty checks apply to every one of them. When a screening service is unavailable, the firm either stops processing or processes without controls, and both outcomes create regulatory exposure.

The practical risk is easy to state. Without real-time monitoring, stolen funds can be accepted, swapped into other assets, and cashed out through the very channels that are meant to stop them. A compliance programme that is well designed on paper still fails in that window, because the control it relies on is not running.

That is why availability belongs in the same conversation as risk scoring, coverage, and data quality when a compliance team assesses a blockchain analytics provider. A screening result is only useful if it arrives when the transfer happens.

Scorechain's API uptime over the last 12 months

The Scorechain API and application averaged 99.98% uptime over the last 12 months, based on the monthly figures published on our public status page. As of November 6, 2026, there have been no incidents since August 20, 2026. The lowest month was July 2026, at 99.86%. Eight of the 12 months recorded 100%.

Source: status.scorechain.com, API and application component, as of November 6, 2026. The 12-month figure is the average of the published monthly values.

Behind those figures, the last 12 months included one full outage: five minutes on August 20, 2026,during a database restart. Every other incident was a partial outage affecting a single blockchain: Solana scoring for 55 minutes in December 2025, Bitcoin for about 16 minutes in June 2026, and TON analytics for 3 hours 22 minutes in July 2026. Each one is recorded in the public incident history. The status page counts a partial outage as 30% downtime, which is why a three-hour incident on one chain appears as a fraction of a percent in the monthly figures

We publish the weaker months alongside the strong ones on purpose. A perfect line of 100% would be less useful to a compliance team than an honest record, because the questions that matter in a vendor assessment are how often service degrades, for how long, and how clearly the provider communicates when it does.

Uptime at production scale

Those figures were recorded under real production load. Across the second and third quarters of 2026, the Scorechain API served more than 300 million calls and the platformr an an average of more than one million transaction monitoring checks a day.

Reaction and repair commitments

Under Scorechain's 24/7 service level agreement, business-interrupting errors carry a one-hour reaction time and a four-hour repair target. SLA terms are shared with customers and prospects during due diligence.

The status page tracks the components customers actually depend on: the Scorechain API, the API and application, login, and www.scorechain.com. Customers can subscribe to incident notifications by email, SMS, Slack, webhook, or RSS, so their own teams are alerted without having to check.

What do 99.9%, 99.95%, and 99.99% uptime mean in practice?

Each additional "nine" in an uptime figure cuts the permitted downtime by a large factor. At 99.9%, a service can be unavailable for almost nine hours a year. At 99.99%, the allowance falls to under an hour. For a screening service, that difference decides how many transfers a compliance team may have to hold or review retrospectively.

Calculated on an average month of 30.4 days and a year of 365 days.

These figures are also how an uptime SLA should be read. A contractual uptime SLA sets the level below which a provider has failed its commitment, so a 99.9% SLA formally permits close to nine hours of downtime a year. When comparing providers, the measured history is the better guide, because a contractual figure describes the minimum a provider commits to, not what it actually delivers.

Uptime, availability, and reliability, what is the difference?

Uptime is the share of time a service is running and reachable, usually expressed as a percentage over a month or a year. Availability is the share of time a service can actually be used as intended, which can be lower than uptime if a system is reachable but too slow or partially broken. Reliability describes how consistently a service performs over time, including how rarely it fails and how quickly it recovers.

Three recovery measures complete the picture:

• Recovery time objective (RTO): the maximum time a service may take to return after a disruption.
• Recovery point objective (RPO): the maximum amount of data, measured in time, that may be lost in a disruption.
• Mean time to recovery (MTTR): the average time a provider actually takes to restore service after an incident.

For a compliance team, uptime answers "how often was screening available," while RTO and MTTR answer "how long would we be exposed if it was not." Both belong in a vendor assessment.

The six commitments behind our uptime

Scorechain treats reliability as an engineering discipline and a design principle, not a certificate. Our approach rests on six commitments: measure reliability in public, monitor every service continuously, design out single points of failure, build on a different architecture, treat security as part of availability, and stay transparent when things go wrong.

Measure reliability in public

Uptime that only appears in a sales deck cannot be verified.

What it means: customers should be able to check our record without asking us.

How we do it: Scorechain publishes component-level status and monthly uptime history on status.scorechain.com, so customers, prospects, and auditors can check the record themselves and reference it in their own vendor assessments.

Monitor every service, all the time

Certifications and periodic tests are a baseline. Continuous monitoring of every service is mandatory.

What it means: every production system is watched around the clock, and a human is accountable for every alert, at any hour.

How we do it:

• Every production service is monitored 24/7/365, including automated checks that test the platform the way customers reach it.
• Alerts fire automatically on predefined thresholds and are routed to an engineering on-call rotation, so detection never depends on a customer reporting a problem.
• The on-call scope covers any outage that limits access to the API or the application, blocks real-time scoring, or interrupts customer workflows such as custody integrations and alerts.

Design out single points of failure

Resilience by design means that no single failure should take a critical service down.

What it means: every critical component has a tested path back, whether that is a second zone, a replica, a backup, or a documented failover.

How we do it:

• Production runs across multiple availability zones, with load balancing in front of critical services.
• Data is backed up frequently and replicated across zones, and documented, tested recovery procedures cover failure scenarios such as the loss of a server or a database.
• Updates ship through a zero-downtime deployment process, so releasing improvements does not interrupt screening.

The same principle applies on the customer side: compliance teams increasingly run more than one analytics provider, so that a disruption at one does not stop screening altogether. Our article on avoiding a single point of failure in crypto compliance covers how to set that up. 

Build on a different architecture

Scorechain's approach differs from many providers in the market. Its platform is hosted in the EU and operated end to end by Scorechain's own engineering team. Detailed infrastructure information is shared with customers under NDA as part of their due diligence. That is not a claim to be better than the alternatives, only different. For teams that want several providers for redundancy, choosing ones built differently is a practical way to avoid sharing the same points of failure.

Treat security as part of availability

Some of the most disruptive outages begin as security incidents, which is why security and availability cannot be managed separately. Scorechain holds ISO/IEC 27001:2022 certification, issued by Insight Assurance and valid until April 9, 2029, covering its SaaS platform, API, real-time transaction monitoring, risk scoring, and KYT capabilities. Scorechain also aligns with the Digital Operational Resilience Act (DORA) in Europe. Scorechain also commissions independent penetration testing from a CREST-accredited firm, most recently a black-box assessment of the Scorechain API in March 2026. With malicious AI agents now part of the threat model, we are actively evaluating how our defences need to evolve.

Stay transparent when things go wrong

Every company is exposed, and no provider can promise 100% safety. What matters is transparency and fast countermeasures to protect customer data. Scorechain communicates incidents through its status page, works to the reaction and repair targets in its 24/7 SLA, and reviews significant incidents to identify the root cause and prevent a repeat. Business continuity and disaster recovery plans are tested every year. In 2026 this included a disaster recovery tabletop exercise, a full restore of the production database in an isolated environment, completed in 3 hours 24 minutes against a four-hour objective, and a test in which production nodes were taken offline without interrupting service. When the safest option is to take a service offline to protect data, doing so can be the responsible call, and customers are better served by a clear notice than by a service that stays up while exposed.

"Certifications and periodic tests are a baseline. Continuous monitoring of every service is mandatory. This isn't about pointing fingers: every company is exposed, and the whole industry has to raise the bar together."
— Pierre Gérard, CEO and co-founder, Scorechain 

What do regulators expect on availability?

No major regulator sets a minimum uptime percentage for compliance tools. Instead, frameworks expect firms to identify critical services, set recovery objectives, map the third parties behind them, and test their continuity plans. A provider's uptime record is part of the evidence a firm uses to show those plans are realistic.

• European Union. DORA has applied since January 17, 2025, and covers crypto-asset service providers (CASPs) authorised under the Markets in Crypto-Assets Regulation (MiCA). It requires firms to test their ICT business continuity plans at least yearly. MiCA itself requires CASPs to establish a business continuity policy that includes ICT business continuity plans under DORA.
• United Kingdom. The Financial Conduct Authority (FCA) requires firms to set impact tolerances for important business services, and states that if a third party fails to remain within impact tolerance, "the failure to remain within impact tolerance is your responsibility."
• Singapore. The Monetary Authority of Singapore (MAS) Guidelines on Business Continuity Management ask financial institutions to set a service recovery time objective for each critical business service.

How to assess a provider's uptime claims

To assess a blockchain analytics provider's reliability, start with its published uptime history, check how incidents are detected and communicated, review its SLA terms during due diligence, and confirm that its security and infrastructure choices support the availability it promises.

Use this checklist in your next vendor assessment:

• A public status page, with component-level status and at least 12 months of history.
• Measured uptime, not only the SLA, reported month by month, including weaker months.
• A clear SLA definition: how uptime is measured, over what period, which components are covered, and what is excluded, usually reviewed during due diligence.
• Recovery commitments, such as RTO and RPO for the services your compliance controls depend on.
• 24/7 incident response, with automated monitoring rather than reliance on customer reports.
• Incident communication through channels your team already uses, such as email, Slack, or webhooks.
• Recognised security certification, such as ISO/IEC 27001.
• Hosting jurisdiction and infrastructure details, which providers typically share under NDA during due diligence.

Frequently asked questions

What is a good uptime SLA for compliance software? 

There is no single right number. Start with the measured, month-by-month history, check how uptime is defined and which components it covers, and review the full SLA terms during due diligence. A long published record of high uptime on the components you depend on says more than a contractual figure alone. Recovery commitments and incident communication matter too.

How much downtime is 99.99% uptime?

99.99% uptime allows about 4.4 minutes of downtime per month, or about 52.6 minutes per year. By comparison, 99.9% uptime allows about 43.8 minutes per month, or about 8.8 hours per year. For a screening service, that difference determines how many transfers may need to be held or reviewed later.

What is the difference between uptime and availability?

Uptime measures whether a service is running and reachable. Availability measures whether it can actually be used as intended. A service can be up but unavailable in practice, for example when it responds too slowly or a key function fails. Compliance teams should ask providers how they measure both.

Does any regulation set a minimum uptime for compliance tools? 

No major framework sets a fixed uptime percentage. DORA, the FCA's operational resilience rules, and MAS guidelines instead require firms to identify critical services, set recovery objectives or impact tolerances, and test business continuity plans. A provider's uptime record helps evidence that those plans are achievable.

Where can I check Scorechain's uptime? 

Scorechain publishes live status and monthly uptime history for its API, application, login, and website at status.scorechain.com. Over the last 12 months, the API and application component averaged 99.98% uptime based on the published monthly figures. As of November 6, 2026, there have been no incidents since August 20, 2026.

Raising the bar together

Reliability is not a feature a compliance team notices on a good day. It is the reason screening is still running on a bad one. Scorechain publishes its uptime, monitors every service continuously, and builds on a different architecture, because compliance teams deserve evidence rather than promises. No single provider can carry that alone, and the whole industry has to raise the bar together.

To see Scorechain's live record, visit status.scorechain.com. To discuss how Scorechain can support your compliance programme, as a primary provider or as an independent second line of screening, book a demo.