1. Executive summary
A ransomware group calling itself Black X listed lopay, a UK fintech that provides card and mobile payment acceptance and settlement services to SMEs and sole traders, on its leak site on 2026-10-09. The listing claims access to client-company financial information including customer payment details, card information, banking data, transaction history and payment terminal information. No CVE is referenced in this item and the VERIFIED REFERENCE DATA records no CISA KEV entry, no CVSS score and no EPSS value for it, so there is no patchable vulnerability to triage here; the exposure is a claimed data-theft and extortion event against a payment processor. The bottom-line risk to EMEA financial services clients is third-party and downstream: any client that uses lopay for payment acceptance, or that banks an SME whose card and settlement data sits with lopay, should treat its own transaction records as potentially exposed until lopay confirms scope. Attribution to Black X is unconfirmed: the VERIFIED REFERENCE DATA holds no MITRE ATT&CK profile for that actor, and the only evidence of the claim is the leak-site post itself.
2. Regulatory framing
| Article | Trigger (the fact in this item) | Practical impact |
|---|---|---|
| DORA Art. 28: ICT third-party risk, general principles | A UK payment platform that financial entities may use for card acceptance and settlement is the named victim of a claimed data-theft and extortion event. | Clients with lopay in their ICT third-party register must obtain lopay's incident status and assess whether the claimed exposure of payment and banking data affects their own contractual service continuity. |
| DORA Art. 29: preliminary assessment of ICT concentration risk | The claimed exposure covers shared payment and settlement data across lopay's SME and sole-trader client base, so multiple financial entities may depend on the same provider. | Where lopay is a concentrated dependency, the preliminary concentration assessment should be revisited with the incident as an input. |
| NIS2 Art. 21(2)(d): supply chain security measures | The event is a supply chain exposure: a service provider in the payment chain is claimed to have lost client financial data. | Entities in NIS2 scope that rely on lopay must review supply chain security measures for that provider and record the incident against them. |
No DORA Art. 17, 18, 19 or 24 row is included: this item does not state that lopay is a financial entity in DORA scope, does not give an incident classification, and does not describe a testing failure. Those articles are not engaged on the facts available.
3. Technical analysis & attack chain
The source material does not describe an attack chain. It is a leak-site listing, not a technical report, and it gives no initial access vector, no exploited component, no CVE, no payload detail, no persistence mechanism, no command-and-control, no lateral movement and no exfiltration method. What follows is limited to what the listing and the related source actually state.
- Black X posted lopay to its leak site on 2026-10-09 at 19:12 UTC, naming the victim as lopay, country GB, website lopay.com.
- The listing describes lopay as a UK fintech providing a payment platform for SMEs and sole traders to accept credit card and mobile payments and to manage sales and settlements.
- The listing claims the data includes financial information belonging to client companies: customer payment details, card information, banking data, transaction history and payment terminal information.
- The related source records one third-party employee credential associated with the victim, and zero compromised employees and zero compromised users.
The single third-party employee credential is the only access-related data point in the sources. It is recorded by ransomware.live, a leak-site indexer, and it is not corroborated by any second source in this item. Whether that credential had any role in the claimed intrusion is not stated. Treat it as a lead for the third-party access review, not as a confirmed initial access vector.
The claim that card information, banking data and transaction history were taken is single-sourced to the operator's own leak-site post. Ransomware operators routinely overstate the scope and sensitivity of what they hold, and ransomware.live explicitly states it does not access or verify the underlying stolen content. Nothing in the sources confirms that card data, banking data or transaction history were actually exfiltrated, and nothing indicates whether the data is encrypted at rest, tokenised or otherwise reduced in value. The listing also does not state whether systems were encrypted, whether a ransom demand was made, or whether lopay has confirmed, denied or responded to the claim. Do not treat the claimed data categories as verified until lopay or a regulator confirms them.
Attribution to Black X is unconfirmed. The VERIFIED REFERENCE DATA contains no MITRE ATT&CK profile for an actor of that name, so no TTP mapping, tooling profile or historical targeting pattern can be attached to this event. The name is the operator's own label on the leak site.
4. Mitigation & containment
P1 within 24h
- Establish whether lopay is in your ICT third-party register and whether any payment acceptance, settlement or reconciliation flow depends on it. If it does, contact lopay directly and in writing for incident status, scope of affected data categories, and whether card, banking and transaction data for your customers is implicated.
- If you are a lopay client and your own customer card or banking data sits in the platform, treat it as potentially exposed and start your own data-subject and card-scheme assessment now rather than waiting for lopay's confirmation. Card-scheme notification clocks run from awareness, not from confirmation.
- Review third-party and vendor access to your payment and settlement systems. The related source records one third-party employee credential associated with the victim; check whether any third-party account in your own environment has equivalent standing access and whether it is still needed.
- Preserve your own transaction and settlement logs for the period lopay holds your data, so that any later reconciliation or dispute work has a clean record independent of the provider.
P2 within 72h
- Re-run the preliminary ICT concentration assessment for lopay as a dependency, covering how many of your payment or settlement flows route through it and what the fallback is if the platform is unavailable or its data is unusable.
- Review the lopay contract against DORA Art. 30 key contractual provisions: incident notification obligations, cooperation on forensics, and audit or information rights. If the contract does not require lopay to notify you of an incident of this kind within a defined window, that gap is the finding.
- Brief your fraud and financial-crime teams. Claimed exposure of customer payment details, card information and banking data is a fraud-enablement risk for your SME customers even where your own systems are untouched.
P3 within 7 days
- Update the third-party risk record for lopay with the incident, the date, the claimed data categories and the outcome of your enquiries, so the next concentration and supply chain review has the history.
- If you are in NIS2 scope and rely on lopay, record the incident against your supply chain security measures for that provider.
No vendor fix, patch or version pin applies to this item. There is no CVE, no affected product version and no vendor advisory in the source material.
5. Indicators of compromise
No atomic indicators of compromise are available in the source material. No file hashes, domains, IP addresses, URLs, filenames, registry keys or command lines are given. The only network identifier present is the victim's own website, lopay.com, which is the victim and not an indicator.
The sources describe one observable access-related fact and one claimed data-exposure fact but no atomic indicators, so they are recorded as behavioural indicators.
| Behaviour | Where to observe | Confidence |
|---|---|---|
| Third-party employee credential associated with the victim | Third-party and vendor account inventory; identity provider logs for external accounts | Single-sourced to ransomware.live; unverified and not linked to the intrusion in the source |
| Claimed exposure of customer payment details, card information, banking data, transaction history and payment terminal information | lopay platform data holdings; your own transaction and settlement records held by lopay | Single-sourced to the operator's leak-site post; scope unverified |
6. Detection
Insufficient indicators to author detection rules.
The sources contain no distinctive strings, command-line flags, mutex names, scheduled-task or service names, file names or paths, registry keys, ransom-note text or hard-coded values. The only artefacts present are the victim's name and domain, which are not threat artefacts and would produce rules that match reporting about the event rather than the event itself.
7. Sources
- ransomware.live, "Victim: lopay – Black X", https://www.ransomware.live/id/bG9wYXlAQmxhY2sgWA==, published 2026-10-09.
- ransomware.live, "Ransomware: Black X named lopay (GB)", https://www.ransomware.live/id/bG9wYXlAQmxhY2sgWA==, published 2026-10-09.
Both sources are the same leak-site index entry. There is no independent corroboration in this item for the claimed data categories, the third-party credential, or the attribution to Black X.
8. Adverse Trace position
Adverse Trace assesses this as a medium-confidence, high-impact third-party event. The impact is potentially high because the claimed data categories are payment card data, banking data and transaction history belonging to a payment processor's client base, but the confidence is limited: the entire claim rests on a single leak-site post, ransomware.live states it does not access or verify the underlying stolen content, and the VERIFIED REFERENCE DATA holds no MITRE ATT&CK profile for Black X, so the attribution is unconfirmed and no TTP profile can be applied. There is no CVE, no CISA KEV entry and no CVSS score in the verified data, so we are not assigning a vulnerability severity to this item. For clients, the exposure is downstream and contractual rather than technical: if lopay is in your payment or settlement chain, your own customers' data may be implicated and your card-scheme and data-protection clocks may already be running. We will monitor the leak site for a data release or a lopay statement, watch for any independent confirmation of the claimed data categories, and re-issue this advisory if the scope is confirmed or if a second source corroborates the credential lead.
Published via PulseTrace — Adverse Trace threat intelligence.