Haruko breach exposes gaps in fintech cyber disclosure

A targeted cyberattack on Haruko, a UK-incorporated, London-based crypto trading infrastructure provider, affected 15 clients and exposed read-only exchange application programming interface (API) details and trading data, according to a CoinDesk report published on 18 September 2026. The report draws on messages reviewed by CoinDesk and three people with knowledge of the matter, including communications attributed to Haruko co-founder and chief technology officer Adam Carlile. CoinDesk also reported, citing unnamed sources and using conditional language, that a small amount of client funds may have been stolen, with possible losses among smaller hedge funds. No affected client, transaction record, amount or forensic report has publicly confirmed any loss, and Haruko did not respond to CoinDesk's requests for comment.

The incident matters to UK financial firms regardless of whether Haruko itself is regulated: a UK-regulated firm within the FCA's or PRA's operational-resilience rules that plugs a third-party technology provider into its trading, custody or data infrastructure must itself map and test that dependency, and, where personal data is involved, assess its own data-protection duties as a controller or processor.

As of 3 October 2026, no public first-party Haruko incident report or technical post-mortem had been located, despite CoinDesk reporting that the company intended to publish one. That gap between what a supplier tells clients privately and what it discloses on the record is the core issue this analysis examines.

What CoinDesk reported, and what remains unconfirmed

CoinDesk's account rests on three distinct types of evidence, and they carry different weight.

First, messages attributed to Haruko's chief technology officer, reviewed by CoinDesk, support the claim that 15 clients were affected and that all 15 lacked inbound internet protocol (IP) address whitelisting — a control that restricts which network addresses can connect to an account or API. The same messages are the source for CoinDesk's claims that Haruko fixed the exploited vulnerability and refreshed server-side secrets.

Second, CoinDesk's claim that a small amount of client funds was stolen rests on unnamed sources, with conditional language about losses among smaller hedge funds. No named client, wallet address, transaction identifier or figure accompanies the claim.

Third, two named firms that CoinDesk identified as Haruko clients — GSR and 3iQ Digital Assets — told the publication they were not affected. 3iQ attributed its lack of exposure to IP whitelisting. These denials do not contradict the reported total of 15, because Haruko's full client list and the identities of the affected 15 are undisclosed.

IP whitelisting restricts connections to pre-approved addresses; CoinDesk reports none of the 15 affected clients had enabled it, while 3iQ's non-exposure was attributed to having it in place. That does not establish what "read-only" access could permit: such credentials would not ordinarily authorise withdrawals, and no public forensic analysis explains how the reported access led to the reported theft. The volume and sensitivity of the exposed "trading data" have not been made public, limiting what any affected firm can say about its own exposure.

Haruko Limited is an active UK private company, company number 13383328, incorporated on 7 May 2021, with its registered business recorded by Companies House as business and domestic software development. That record establishes Haruko's corporate existence. It does not establish Financial Conduct Authority (FCA) authorisation, custody permissions, or critical-third-party designation.

What good supplier disclosure should contain

UK rules for a narrower category of supplier — designated critical third parties, discussed below — set out a useful structure for what any provider should tell an affected client after an incident, even though that structure is not a direct legal duty on Haruko.

That structure separates disclosure into stages: an initial report covering the scope of the incident, detection time, affected services and credentials, geographical scope, known cause, response actions and expected recovery time, with a contact point; intermediate updates as the picture develops; and a final account covering root cause, remediation, recurrence risk and lessons learned.

Measured against that structure, the public record on Haruko is thin. There is no independently verified timeline of detection and containment. There is no client-by-client account of what "affected" means — whether it means data viewed, data taken, credentials usable by an attacker, account compromise, or confirmed financial harm. There is no published root-cause analysis. None of this means Haruko has broken an applicable rule; it means a UK firm should not treat vague, private updates from any supplier as sufficient, regardless of a specific statutory duty.

UK firms remain accountable for their suppliers

UK-regulated firms do not transfer their operational-resilience obligations to a supplier simply by outsourcing a function to it. The FCA's operational-resilience rules, in force since 31 March 2022, require in-scope firms to map third-party dependencies supporting their important business services and operate within impact tolerances for them. In-scope firms had until 31 March 2025 to complete that mapping, testing and any investment needed to stay within tolerance.

For PRA-regulated firms in scope, Supervisory Statement SS2/21, effective from 31 December 2024, sets out expectations covering due diligence, contractual and audit rights, data security, sub-outsourcing, business continuity and exit strategies.

The scale of the risk is not abstract: the FCA says more than 40% of cyber incidents it received in 2025 involved a third party — a figure confined to incidents reported to the FCA, not all UK cyber incidents.

Reporting duties today, and what changes on 18 March 2027

Current FCA duties, the incoming 2027 reporting regime and a separate UK GDPR deadline apply in different circumstances and should not be conflated.

Under the FCA's current rules, firms within scope must comply with Principle 11: dealing openly with the regulator and disclosing anything it would reasonably expect notice of. The FCA's guidance lists indicators of a reportable incident: material disruption, effects on many customers, unauthorised access, significant data loss, or loss of control of IT systems. SUP 15.3 separately requires immediate notification of matters with serious regulatory impact. Whether a supplier incident is "material" for a given firm depends on that firm's own exposure, not the supplier's statements.

On 18 March 2026, the FCA published its final policy statement for a standardised operational-incident and material-third-party reporting regime, covering the FCA, PRA and Bank of England; the rules take effect on 18 March 2027. From that date, the regime introduces standardised incident reporting, notifications for new or significantly changed material third-party arrangements, registers of those arrangements, and annual register submissions for firms in scope.

UK GDPR separately requires a controller to notify the ICO within 72 hours of awareness, where feasible, when a personal-data breach is likely to result in a risk to individuals' rights and freedoms; a processor must tell its controller without undue delay, and phased reporting is allowed. Whether this applies to the Haruko incident cannot be assessed: it is not established whether personal data was involved, or whether Haruko acted as controller, processor or neither.

Critical third parties are a narrow category — Haruko was not among the July 2026 designations

The UK's critical-third-party regime imposes the most detailed incident-disclosure duties of these frameworks, but it applies only to HM Treasury-designated providers. HM Treasury's announcement of 10 July 2026 named four, effective from 13 July 2026: Microsoft Ireland Operations Limited, Google Cloud EMEA Limited, Amazon Web Services EMEA SARL and Oracle Corporation UK Limited. Haruko was not among them, and no evidence of a later designation had been found as of 3 October 2026.

Designated critical third parties must, under CTPS 8, give affected firms and regulators an initial description, detection time, affected services, known cause, response actions and expected recovery time, then updates and a final account of root cause, remediation and recurrence risk. That is a demanding standard and a fair benchmark for supplier disclosure, but it is not a direct duty on Haruko: there is no evidence of designation, and the regime covers only providers whose failure could threaten UK financial stability.

HM Treasury has said designation does not remove responsibility from firms that use a critical third party; the same logic applies more strongly to Haruko and other undesignated suppliers. Designation is a rolling process, and this snapshot reflects the position as of 3 October 2026.

A short due-diligence checklist

This reflects general FCA, PRA and critical-third-party expectations for managing supplier risk, not a Haruko-specific duty:

• Confirm what credentials and permissions a supplier held, and whether they have been rotated.
• Check that IP whitelisting, least-privilege access and anomaly monitoring were all in place.
• Seek independent forensic evidence of root cause, not just a supplier's own account.
• Establish what data was exposed, and whether any of it triggers a UK GDPR assessment.
• Review contractual notification times, audit rights and exit provisions.

What to watch next

The facts that would resolve the open questions have not surfaced publicly: Haruko's promised post-mortem, named client confirmation, verified evidence of loss, and any record of notification to the FCA, PRA, ICO or law enforcement. Readers can consult the FCA's guidance on reporting operational incidents, the PRA's SS2/21, the ICO's breach guide and HM Treasury's critical-third-party announcements, rather than relying on commercial breach summaries.