The Dark Army

Author: Ethan Miller

  • How UK Banking Apps Are Silently Killing Sessions, Hiding Error Codes, and Gaslighting Users: The Interface Engineering Behind ‘Unexpected Errors’

    How UK Banking Apps Are Silently Killing Sessions, Hiding Error Codes, and Gaslighting Users: The Interface Engineering Behind ‘Unexpected Errors’

    There is a specific kind of rage reserved for staring at a white screen that says “We’re experiencing technical difficulties. Please try again later.” You have no idea if your payment went through. You have no idea if your session is alive or dead. You have no idea if the problem is your connection, the bank’s servers, or some silent fraud flag that just locked your account without telling you. That is not an accident. UK banking apps are engineered to behave exactly this way, and I think it is worth pulling apart why.

    Smartphone displaying a banking app error state during failed session — banking app error states explained
    Photo by Tranmautritam on Pexels

    What “something went wrong” actually means technically

    When a Barclays or Lloyds app throws a generic error, what is happening under the bonnet is usually one of several distinct failure states that the application is deliberately collapsing into a single unreadable message. HTTP 5xx errors from the backend, certificate pinning mismatches, OAuth token expiry, failed biometric challenge responses, rate-limit rejections from the authentication API, all of these have different causes, different recovery paths, and different implications for the user. They get flattened into the same beige modal box.

    This is a deliberate engineering decision. The reasoning given internally is always security: exposing specific error codes gives an attacker more signal. If the app tells you “incorrect PIN, 2 attempts remaining”, an attacker probing accounts knows the PIN space to target. Fair point, up to a point. But the same logic gets applied so aggressively that legitimate users get zero actionable information. Banking app error states end up communicating nothing at all, which is genuinely worse from a usability standpoint and arguably no better from a security one, since a determined attacker just fuzzes the API directly and ignores the UI entirely.

    Session management: the silent kill

    Session timeouts are where things get particularly nasty. Most UK banking apps run aggressive idle timeouts, Nationwide and HSBC both drop sessions after roughly 5 minutes of inactivity in-app, though neither documents the exact threshold publicly. The timeout itself is not the problem. The problem is the transition. A well-engineered app tells you clearly that your session expired and puts you back at a login screen with a clear message. What I have seen repeatedly in practice is something different: the app silently kills the session in the background while leaving the UI in an apparently functional state, so the next action you take, submitting a payment, confirming a standing order, fails at the API layer with no context. The error that surfaces is a generic one, because the session state mismatch gets caught somewhere in the middleware and rethrown as a 500-level response that the frontend handles with its default catch-all handler.

    The result is that users assume the bank’s servers are down, retry the payment, and in some cases submit duplicate transactions. I have seen this pattern cause real financial confusion for people, and the banks’ response is almost always to point at their terms of service rather than acknowledge the session handling is broken.

    Terminal showing authentication error codes related to banking app error states and session management
    Photo by Rafael Minguet Delgado on Pexels

    Authentication throttling and the feedback blackout

    Authentication rate limiting is another place where the engineering decisions get questionable. Throttling login attempts is essential, nobody is arguing against it. But the way UK banking apps implement the feedback around throttling is often actively misleading. When Monzo or NatWest throttles your authentication attempts, the common pattern is to introduce artificial delays without telling you a delay is happening. The spinner just spins. Is it your network? Is it the server? Are you being throttled? You genuinely cannot tell. Some apps go further and return an identical-looking error to a genuine failure, so you cannot distinguish “wrong credentials” from “you have been temporarily locked out” from “the auth service is actually down”.

    Compare this to how a well-designed system handles throttling: clear messaging that says something like “too many attempts, please wait 30 seconds”, a visible countdown, and a distinction between soft lockout and full account lockout. This is not exotic engineering. It is just honest UI. The reason it does not happen in most UK banking apps is partly legal caution, the compliance and legal teams are terrified of confirming to a potential fraudster that an account exists and has been locked, and partly because nobody senior enough cares enough to push back on the default of “hide everything”.

    For a broader look at how this pattern of bad feedback design causes real financial and time costs across digital products, a longer read on why ux design failures in everyday apps are costing british users time, money and patience is worth your time, the problems in banking apps are not isolated.

    The ambiguous UI flow problem

    Beyond individual errors, UK banking apps have a systemic problem with ambiguous state across multi-step flows. Payment journeys are the worst offenders. A typical faster payments flow across Santander or TSB involves four to seven screens depending on the transaction type. At each step, the app holds state locally in memory. If anything causes a page reload or app backgrounding mid-flow, a phone call, a low-memory event killing the app process, a brief network drop, the local state is gone. The app often lands you back at the start of the flow with no indication of whether the previous attempt completed at the server side or not.

    This is genuinely dangerous for users. The PSD2 open banking API surface that sits under these flows does have idempotency key support in most modern implementations, but many of the older in-app payment flows were built before that became standard practice and never properly refactored. The banking app UI layer and the API layer are often built by entirely different teams on different release cycles, and the integration between them is where the worst ambiguous states live.

    Why the FCA is not really fixing this

    The FCA’s Consumer Duty, which came into full effect in July 2023, theoretically requires firms to deliver “good outcomes” for consumers and to avoid “foreseeable harm”. Deliberately obscured banking app error states that leave users confused about whether their money moved seem like exactly the kind of thing Consumer Duty should catch. In practice, the FCA’s published guidance on Consumer Duty focuses heavily on pricing, communications, and support access rather than the technical engineering of UI feedback. Nobody is getting fined for a bad error modal.

    The result is that the incentive structure for banks is almost entirely one-directional: minimise information exposure for risk and compliance reasons, and never face meaningful regulatory consequences for the usability degradation that causes. Security teams win every internal argument because they have a clear threat model to point at. UX teams pushing for better error communication have no equivalent forcing function.

    What good looks like, and why banks avoid it

    Starling Bank is probably the closest thing to a counter-example in UK retail banking. Their app gives noticeably more specific error messages, distinguishing between declined transactions, insufficient funds, card not enabled for international use, and service outages, without apparently handing attackers useful signal. This is achievable because the specificity is contextual: once a user is authenticated and in their own account session, the threat model is different from the pre-auth login flow. The information is only relevant to that authenticated user. It is not obvious attack surface.

    The reason most high street banks do not do this is inertia and risk aversion, not technical impossibility. The engineering required to map specific backend failure codes to useful, user-facing messages is not complex. It is a product prioritisation decision, and it keeps losing to other priorities because nobody at board level is tracking “user session confusion rate” as a metric that matters.

    My take: the engineering behind UK banking app error states is a small but revealing window into how financial institutions actually value their users. Treating authentication throttle feedback as a security necessity while ignoring the financial confusion caused by ambiguous payment states is not a coherent position. It is just the path of least resistance, and it costs ordinary people time and money every day. The same engineering literacy that goes into hardening the authentication stack should go into making the failure states legible. Right now, it does not. And as we have written about before in the context of property fraud infrastructure built on ambiguous communications, opacity in digital financial interfaces is rarely neutral, someone always pays for it.

    Frequently Asked Questions

    Why do UK banking apps show vague error messages instead of specific codes?

    Banks collapse specific failure states into generic errors primarily for security reasons, exposing precise error codes could give attackers useful signal about account status or authentication logic. However, this rationale is often applied far too broadly, stripping out information that would only be useful to authenticated users who pose no additional threat.

    What causes a banking app session to die without warning?

    Most UK banking apps run aggressive idle timeouts, typically between 3 and 10 minutes, and some kill the session silently in the background while leaving the UI in a seemingly active state. This means the next action you take hits an expired session at the API layer, which surfaces as a generic error rather than a clear session-expired message.

    Can a banking app accidentally send a payment twice if I retry after an error?

    It is possible, particularly in older in-app payment flows not built on idempotency keys. If the app loses local state mid-flow and you restart the payment, the second attempt may go through even if the first one processed at the server side. Always check your transaction history before retrying a failed payment.

    Does the FCA regulate how banking apps handle error messages?

    The FCA’s Consumer Duty requires banks to deliver good outcomes and avoid foreseeable harm, which could theoretically cover deliberately confusing UI design. In practice, the FCA’s enforcement focus has been on pricing, communications, and complaints handling rather than the technical specifics of in-app error feedback.

    Which UK banking apps have the best error handling?

    Starling Bank is generally considered the strongest in this area among UK retail banks, providing contextual, specific error messages post-authentication that distinguish between different failure types. Most traditional high street banks lag significantly, defaulting to catch-all generic messages across nearly all failure states.

  • How UK Train Operators and TfL Are Harvesting Passenger Behaviour Data Through Oyster, Contactless, and App Telemetry

    How UK Train Operators and TfL Are Harvesting Passenger Behaviour Data Through Oyster, Contactless, and App Telemetry

    Every time you tap in at a Tube station or scan your phone on a Southern Rail barrier, you’re generating a timestamped, location-stamped record that sits inside at least three different databases. Most passengers assume the data is just used to charge the right fare. It isn’t. The full picture of what gets logged, who it gets shared with, and what it reveals about your daily life is considerably more interesting than TfL or any of the train operators are volunteering to tell you.

    Underground station ticket barriers where National Rail Oyster data privacy UK tracking begins at the tap-in point
    Photo by MART PRODUCTION on Pexels

    I’ve spent time pulling apart the privacy notices, data sharing agreements, and API documentation sitting across TfL’s developer portal, the National Rail Enquiries infrastructure, and the major train operating company apps. What’s buried in there is not reassuring. This is a breakdown of the actual technical picture.

    What an Oyster card actually logs

    The Oyster card itself holds minimal data on the chip: your balance, the last eight journey records, and a few pass definitions. That’s intentional. The chip is MIFARE DESFire, and the on-card storage is tightly constrained. But that local data is almost beside the point. The real picture lives on TfL’s back-end systems.

    Every tap-in and tap-out event generates a transaction record containing your Oyster card UID, the station or bus stop ATCO code, a timestamp accurate to the second, the validator ID (which maps to a specific gate or reader), the fare deducted, and a running journey state flag. These records are batched from validators and pushed to TfL’s data warehouse. For registered Oyster users, those records are linked to your name, address, email, date of birth, and any associated payment method. TfL retains identifiable journey history for registered cards for eight weeks by default, according to their privacy notice, though anonymised journey data is retained for much longer and fed into their network planning systems.

    If you use an Oyster card that isn’t registered, the journey data still exists on TfL’s systems tagged to the card UID. That UID is a stable pseudonymous identifier. Pair it with a single registration event (say, you topped it up online once) and TfL can retroactively link every journey you made before and after that event.

    Contactless payment cards and the bank data bridge

    Contactless is where National Rail Oyster data privacy UK tracking gets genuinely complex. When you tap a Visa or Mastercard on a TfL or National Rail reader, the transaction goes through a different chain. TfL processes contactless through a back-end operated by Cubic Transportation Systems (now part of Omdia’s transport portfolio). Cubic holds the journey-level data and reconciles it against the card’s PAN (Primary Account Number) to apply daily and weekly fare caps.

    Critically, this means Cubic holds a dataset mapping your bank card to precise journey times and locations. The data sharing agreement between TfL and Cubic allows Cubic to use aggregate and anonymised data for service improvement. Whether “anonymised” is doing any meaningful work there is a legitimate question given that re-identification of transit data is well-documented in academic research. A 2013 MIT study on mobile phone data demonstrated that just four spatial-temporal data points are enough to uniquely identify 95% of individuals. Transit tap data has comparable density.

    Train operators running their own contactless infrastructure outside London (for example, Avanti West Coast’s ticketing gates or TransPennine Express’s readers) operate a similar model, usually through Flowbird or Scheidt & Bachmann back-ends. The specifics of those data retention and sharing arrangements vary by operator and are buried in procurement contracts that aren’t published.

    What the train operator apps actually collect

    This is where I found the most aggressive data collection hiding in plain sight. The major TOC apps (Trainline being the big aggregator, plus operator-specific apps from Avanti, LNER, and others) collect considerably more than just your booking history.

    Trainline’s Android app requests location permissions, and whilst the app frames this as “show nearby stations,” the location calls happen during background sessions if you leave the permission on “always allow.” Trainline’s privacy notice confirms they collect “device information, usage analytics, and location data” and share these with “advertising partners and analytics providers.” Their listed third-party recipients include Braze for push notification analytics, Amplitude for product analytics, and Adjust for mobile attribution. Adjust in particular is an advertising measurement platform whose primary function is cross-app tracking.

    LNER’s app, built on a Salesforce marketing cloud back-end, logs every search query you make, the tickets you view but don’t purchase, and the times you open the app. That behavioural data feeds into their CRM segmentation and is used for retargeted email campaigns. This isn’t nefarious on its own, but most passengers have no idea their abandoned train search at 07:14 on a Tuesday is being recorded and stored against their account profile.

    The National Rail app built on the NRE (National Rail Enquiries) API layer similarly logs journey plan queries. NRE is jointly owned by the train operating companies through the Rail Delivery Group, and their data governance documentation is sparse on specifics about what third parties receive query-level data.

    The OSINT and profiling potential buried in the data

    Here’s the uncomfortable bit, and the reason this data deserves more scrutiny than it gets. A full journey history for a regular commuter is an extraordinarily detailed behavioural profile. From consistent tap-in times at a local station, you can infer home location to postcode level. From tap-outs at specific destinations, you can infer workplace. Irregular journeys late at night on weekends map social patterns. Journeys to hospital stations (St Thomas’, the Royal Marsden, Great Ormond Street) carry obvious sensitive inferences.

    This is not hypothetical. TfL has already demonstrated this data’s sensitivity by being required under the UK GDPR (enforced by the ICO) to respond to Subject Access Requests with journey logs. Passengers who’ve made SARs have received spreadsheets showing every tap event for months. That’s useful for fraud disputes. It also illustrates exactly how granular and linkable the dataset is.

    For anyone doing open-source intelligence work, a compromised TOC account or a successful social engineering attack on a TOC’s customer service operation would yield a ready-made movement history. It’s the kind of attack surface that sits alongside the UK’s national ANPR network in terms of what it reveals about a person’s physical movements. The two datasets, if correlated, would be extraordinarily powerful for surveillance.

    Train operators have also been caught sharing data with law enforcement beyond what most passengers would expect. Under the Regulation of Investigatory Powers Act (RIPA) and successor legislation, TOCs can receive lawful requests for journey data from police forces without notifying the passenger. The volume of such requests is not publicly reported in a consolidated form.

    Data sharing with third parties: the small print

    Beyond law enforcement, the third-party sharing landscape is messy. Most TOC privacy notices list recipients including: payment processors, fraud prevention agencies (where CIFAS and related bodies come in), marketing analytics platforms, cloud infrastructure providers (AWS and Azure both host significant parts of the rail industry’s data stack), and “business partners.”

    That last category is the one that should get your attention. For rail operators, “business partners” can include hotel chains (booking add-ons), taxi and rideshare platforms (last-mile integrations), and travel insurance providers. Every integration is a potential data pipe. I’d argue the industry’s approach to third-party data sharing is no tighter than the telematics black box ecosystem, where movement data leaks through poorly secured APIs to parties the end user has never heard of.

    The Rail Delivery Group published a data strategy document in 2024 that explicitly frames passenger journey data as an asset for “commercial development and retail partnerships.” That’s the clearest signal yet about how the industry views this data. Not as a byproduct of ticketing, but as a revenue stream.

    What you can actually do about it

    Using an unregistered Oyster card reduces but doesn’t eliminate linkability, since TfL can still correlate the UID with any online top-up. Cash top-ups at machines without logging in are the closest you’ll get to pseudonymous travel on the network. Contactless bank cards are worse because the PAN links directly to your bank identity.

    For app usage, the standard advice applies: review permissions, disable location when the app isn’t active, and use the web browser version of booking platforms rather than the app where possible. Browser-based sessions typically have less telemetry access than native apps, though cookies and fingerprinting still apply.

    Making a Subject Access Request to TfL (and to Trainline or your TOC of choice) is illuminating if you want to see exactly what they hold. Under UK GDPR you’re entitled to a copy of all personal data, and the process is free. TfL has an online SAR portal. Most TOCs take the full statutory 30 days and some push back on scope. This kind of investigation sits in the same territory as looking at how CIFAS and fraud prevention databases build profiles about you from multiple sources without your knowledge: the data exists, it flows, and most people never think to ask what’s in it.

    The rail industry’s data practices need proper scrutiny from the ICO, not just boilerplate privacy notices. Until that happens, every tap of your Oyster is doing more work than moving the barrier gate.

    Frequently Asked Questions

    How long does TfL keep my Oyster journey history?

    For registered Oyster accounts, TfL retains identifiable journey data for eight weeks. Anonymised and aggregated journey data is kept considerably longer for network planning purposes. If you’ve made a web top-up, TfL can also link your card UID to your account retroactively, covering journeys made before registration.

    Is using a contactless bank card on trains more private than an Oyster card?

    No, in most ways it’s less private. Contactless transactions link your PAN (Primary Account Number) directly to your bank identity, and the back-end processor (typically Cubic for TfL) holds journey-level data mapped to that card. An unregistered Oyster card uses a pseudonymous UID, which is harder (but not impossible) to link to your real identity.

    What data do train operator apps like Trainline collect?

    Trainline collects device information, location data (if permitted), usage analytics including searches and viewed-but-not-purchased tickets, and shares this with third parties including Braze, Amplitude, and Adjust. Adjust is specifically a cross-app advertising measurement platform, meaning your behaviour can be tracked across other apps on your device.

    Can UK police access my train journey records without telling me?

    Yes. Under the Regulation of Investigatory Powers Act and successor legislation, train operators can be required to provide journey data to law enforcement without notifying the passenger. There is no consolidated public reporting on how frequently these requests are made across the industry.

  • How UK Fintech Open Banking APIs Are Being Probed by Automated Attackers: The PSD2 Attack Surface Nobody Talks About

    How UK Fintech Open Banking APIs Are Being Probed by Automated Attackers: The PSD2 Attack Surface Nobody Talks About

    Open Banking was sold to the public as a revolution: give your bank’s data to a third-party app, get better budgeting tools, cheaper loans, smarter investing. And to be fair, it delivered on a lot of that. But here’s what the press releases quietly skipped over. When you mandate a standardised API layer across every regulated bank in the country, you also hand attackers a standardised, publicly documented attack surface with consistent endpoint naming conventions, shared OAuth 2.0 flows, and predictable error responses. That is the Open Banking API security UK PSD2 attack problem that almost nobody in the mainstream conversation is actually willing to name.

    Hacker probing Open Banking API security UK PSD2 attack surface at a dark terminal setup
    Photo by cottonbro studio on Pexels

    I’ve spent a fair amount of time reading through the Open Banking Implementation Entity (OBIE) specifications, watching traffic in Burp, and reading the FCA’s published API security expectations. What follows is a technical walkthrough of where the real risk sits, and why automated probing of these endpoints is both easier and more rewarding for attackers than most fintech marketing teams would like to admit.

    What the PSD2 API layer actually looks like

    The Second Payment Services Directive, as implemented in the UK through the Payment Services Regulations 2017, required all banks above a certain size to open up transactional data and payment initiation to authorised Third Party Providers (TPPs). The OBIE produced the Open Banking Standard, which defines REST endpoints, JSON payloads, and the OAuth 2.0 with PKCE and mTLS flows that govern access.

    The endpoints are public knowledge. The specification is online. The error codes, the token endpoint paths, the consent object schema, all of it is documented and largely consistent across every major UK bank. Barclays, HSBC, Lloyds, NatWest: they all expose /open-banking/v3.1/aisp/accounts or a very close variant. Attackers do not need to fingerprint anything. The reconnaissance is done for them.

    The authorisation flow uses Dynamic Client Registration (DCR) in many implementations, meaning a TPP can register a new OAuth client programmatically by presenting a signed Software Statement Assertion (SSA) from the Financial Conduct Authority’s directory. That directory is the trust anchor. If you can get a legitimate SSA, or compromise one, you have a path into every bank’s DCR endpoint simultaneously.

    Credential stuffing at the consent screen layer

    The most common automated attack I see discussed in threat intel circles is not against the API endpoints themselves, it is against the redirect flow that delivers the user to their bank’s own consent screen. Here is the thing: the Open Banking standard does not govern what that consent screen looks like or how banks rate-limit authentication attempts on it. It is effectively a standard login page with a fancy OAuth context bolted on.

    Credential stuffing tools like Sentry MBA or generic Python scripts using aiohttp can hammer these consent endpoints with leaked username/password combos from breach databases. The Open Banking redirect just gives attackers a cleaner, more predictable URL structure to target. Banks are supposed to implement strong customer authentication (SCA) under the Payment Services Regulations 2017, which mandates multi-factor authentication, but the quality of that implementation varies enormously. Some banks are genuinely solid. Others are still leaning on a six-digit SMS code, and as I covered in detail on this blog, SIM swap fraud is actively defeating that exact control at UK banks right now.

    Consent token abuse: the attack the spec quietly enables

    Once a user authorises a TPP, the bank issues an access token bound to a specific consent object. That consent object defines what the TPP can read: account balances, transaction history, beneficiaries. The access token is typically short-lived, but a refresh token can persist for 90 days under OBIE rules.

    Here is where it gets interesting from an attacker’s perspective. If a TPP’s infrastructure is compromised, every stored refresh token is effectively a persistent read-access credential into every connected user’s bank account. The attacker does not need to touch the bank’s systems at all. They hit the TPP, extract the refresh token store, and then quietly poll account data through the legitimate API. The bank sees clean, authorised requests. There is no anomaly to detect unless you are doing behavioural analysis on access patterns at the TPP level.

    There is a documented real-world parallel in the way wallet-draining smart contracts are disguised as legitimate FCA-registered platforms to harvest authorisation from users. The underlying mechanic is the same: abuse the trust infrastructure to get a legitimately issued credential, then exploit it quietly.

    The OBIE spec does allow banks to implement token binding and require mTLS between the TPP and the bank’s resource server, which ties the token to a specific client certificate. But not every bank enforces mTLS at the resource server for every call, and certificate management at smaller TPPs is often treated as a box-ticking exercise rather than an operational security control.

    What the FCA’s API security expectations actually say

    The FCA published its expectations for firms under SYSC (Senior Managers Arrangement, Systems and Controls) and through its participation in the European Banking Authority’s guidelines on ICT risk. The short version: firms must implement appropriate technical and organisational measures, conduct regular vulnerability assessments, and have incident response plans. The FCA’s Open Banking guidance page is worth reading if you have not already, though it reads with the kind of careful vagueness that regulators favour.

    What the FCA does not do is specify how banks should implement rate limiting on API endpoints, what WAF rules should be in place, or how refresh token stores should be encrypted at rest. That is left to firms. In practice, this means a spectrum from genuinely hardened implementations at large banks with dedicated security engineering teams, to TPPs running their token stores in a poorly configured RDS instance on AWS with overpermissive security groups.

    Automated scanning tools, and I am talking about everything from Nuclei templates targeting Open Banking endpoints to custom Python scrapers checking DCR endpoint exposure, are actively looking for misconfigured implementations. The attack surface is consistent enough that you can build a generic scanner and hit every UK bank’s Open Banking base URL systematically. That is not a hypothetical; threat actors are doing exactly this.

    Where the real risk lands for users

    For most people, the most plausible harm from Open Banking API attacks is not a direct bank breach. It is a compromised TPP leaking their financial data to someone who then uses it for targeted fraud. Transaction history reveals salary, regular bills, subscriptions, and financial stress signals. That data is enormously valuable for social engineering. An attacker who knows you have a standing order to a specific solicitor, for example, has the raw material for the kind of technically engineered conveyancing fraud that has cost UK homeowners millions.

    Payment initiation APIs carry a harder risk. A TPP with payment initiation permissions that gets compromised can have those permissions abused to initiate payments directly. The confirmation of payee system helps, but it is not foolproof, and social engineering around it is well understood by fraud groups.

    What a hardened Open Banking implementation actually needs

    From a technical standpoint, the minimum viable security posture for a TPP or bank in this space should include mutual TLS enforced end-to-end, not just at registration; refresh token rotation on every use with single-use semantics; anomaly detection on access patterns per consent object; short-lived access tokens (15 minutes maximum); webhook endpoint validation using signed JWTs; and DCR endpoints that are not exposed to the public internet without IP allowlisting.

    Most of these are in the OBIE spec as options. The word “option” is the problem. Making mTLS optional in a financial API that handles account data is the kind of decision that looks fine until a mid-tier TPP gets popped and 200,000 people’s transaction histories end up in a Telegram channel.

    My read of the current state: the large banks have mostly got this right at the infrastructure level. The weak points are in the ecosystem of smaller TPPs, the budget fintech startups chasing FCA authorisation, and the consent screen UX flows that users click through without reading. The spec created a level playing field for developers. It also created a level playing field for attackers. That was always going to be the trade-off, and I am not convinced the industry has been honest enough about it.

    Frequently Asked Questions

    What is Open Banking and why does PSD2 create an API attack surface?

    Open Banking requires regulated UK banks to expose standardised REST APIs so authorised third parties can access account data and initiate payments on a customer’s behalf. Because the API specification is public and consistent across all major banks, attackers can build generic tools to probe every participating bank without needing to fingerprint individual implementations.

    How does credential stuffing target Open Banking consent flows?

    When a user initiates an Open Banking connection, they are redirected to their bank’s consent and login screen. Attackers use automated tools loaded with leaked username and password combinations to hammer these screens. The Open Banking redirect provides a predictable URL structure, and the quality of rate limiting on these screens varies significantly between banks.

    What is consent token abuse in Open Banking and how does it work?

    After a user authorises a third-party app, the bank issues access and refresh tokens tied to a consent object. If the third-party provider’s servers are compromised, attackers can steal those refresh tokens and silently query account data through legitimate API calls for up to 90 days. Banks see authorised requests and have no inherent reason to flag them as suspicious.

    What does the FCA require from firms regarding Open Banking API security?

    The FCA requires firms to implement appropriate technical and organisational security measures, conduct regular vulnerability assessments, and maintain incident response plans under SYSC rules. However, the FCA does not prescribe specific controls like WAF rules or token encryption standards, which means the quality of implementation varies widely across the ecosystem.

  • How Fake UK Solicitor and Conveyancing Scams Are Technically Engineered: DNS Spoofing, Email Interception, and Property Fraud Infrastructure

    How Fake UK Solicitor and Conveyancing Scams Are Technically Engineered: DNS Spoofing, Email Interception, and Property Fraud Infrastructure

    Property fraud is one of the cleanest and most technically elegant crimes running in the UK right now. A single successful hit can net a criminal gang £300,000 or more from a single redirected bank transfer, with victims who are often highly educated professionals who checked everything they thought they needed to check. UK conveyancing fraud email interception is not some crude phishing play. The infrastructure behind it is patient, layered, and disturbingly professional.

    I’ve spent time pulling apart the mechanics of these attacks, and what strikes me every time is how thoroughly the attackers understand the conveyancing process itself. They know the timeline, they know the language solicitors use, and they know exactly when to strike. Here’s how it actually works at the technical level.

    Hacker analysing email infrastructure related to UK conveyancing fraud email interception
    Photo by Sora Shimazaki on Pexels

    Cloning a law firm’s domain: the first move

    The attack almost always starts with a lookalike domain. A legitimate firm might operate from smithsonssolicitors.co.uk. Within minutes of that domain being identified as a conveyancing firm handling high-value transactions, an attacker registers smithsonssol1citors.co.uk, smithsons-solicitors.co.uk, or a homoglyph variant using Unicode characters that render identically in most email clients. Registering a plausible .co.uk variant costs less than £10 on Namecheap or 123-reg, and it’s trivially easy to find conveyancing firms through the Law Society’s solicitor finder, Land Registry completion data, and Google Maps reviews that often name the firm mid-sale.

    Once the lookalike domain is live, the attacker configures it properly: MX records pointing to a mail server they control, SPF records set to pass basic spam filters, and often a DKIM signing key so outbound emails clear authentication checks at the recipient’s end. Many of these rogue domains also get a cloned website, sometimes scraped verbatim from the real firm’s site, because buyers occasionally Google the firm name and landing on a professional-looking page reduces suspicion. This is where the overlap with legitimate web infrastructure becomes uncomfortable: the techniques used to build and verify a convincing online presence, checking how domains appear in Google, auditing how a site looks to outside crawlers, running a free SEO check to see what a site signals to search engines, are effectively the same techniques attackers use to make their fake infrastructure look credible. Search Engine Tuning, a UK-based SEO service specialising in free SEO checks and domain visibility analysis (searchenginetuning.co.uk), operates in exactly this space legitimately: helping real businesses understand what Google sees when it reads their domains. Criminals are doing the same audit, just without the honesty about intent. Checking your SEO and domain footprint is how defenders spot spoofed sister domains before they’re weaponised.

    Getting into the email thread: MITM at the application layer

    The cloned domain is just the launch pad. The real attack is UK conveyancing fraud email interception, and it operates in two distinct modes depending on how much access the attacker has managed to get.

    Mode one: passive monitoring with delayed injection. The attacker compromises either the buyer’s email account, the seller’s, or (most lucratively) the email server of the actual solicitor’s firm. Credential stuffing, spearphishing a paralegal, or exploiting an exposed Outlook Web Access panel are all common entry points. Once in, they set silent forwarding rules. Every email thread touching keywords like “completion”, “exchange”, “bank details”, or “transfer” gets a blind copy to their monitoring account. They sit and read for weeks. They learn the names, the tone, the running jokes between parties. When completion day approaches and bank details are about to be sent, they act.

    Mode two: domain-based impersonation without account access. Without a foothold on the real mail server, the attacker uses their lookalike domain to inject themselves. They email the buyer from the fake domain pretending to be the solicitor, referencing real details scraped from LinkedIn, the Land Registry, and any public documents filed at Companies House. The buyer, who has been corresponding with @smithsonssolicitors.co.uk for three months, gets one email from @smithsons-solicitors.co.uk and doesn’t notice the hyphen.

    Email header forensics showing routing data used to trace UK conveyancing fraud email interception
    Photo by Sora Shimazaki on Pexels

    The bank detail switch: timing and social engineering

    The switch itself is almost always timed to completion week. That’s when the pressure is highest, the amounts are largest, and buyers are mentally exhausted from months of process. The attacker sends an email that looks like a routine update from the solicitor: “Please note our banking details have changed due to an internal account migration. Please use the following account for your completion funds.” The message is written to match the real solicitor’s communication style precisely, because the attacker has been reading their emails for weeks.

    The account they provide is a mule account, typically a UK personal or business account opened with synthetic or stolen identity documents, sometimes a recently incorporated company with a plausible name. The buyer transfers £250,000 to £600,000. It clears. The mule account empties within hours, the funds moving through a chain of crypto exchanges, hawala networks, and overseas wire transfers that fragment the trail almost immediately.

    By the time the real solicitor calls to ask where the completion funds are, the money is already distributed across three jurisdictions. The Action Fraud reporting process gets triggered, a crime reference number is issued, and the investigation moves at a pace completely incompatible with the speed at which the funds dispersed.

    How investigators trace the infrastructure

    The good news, such as it is, is that the infrastructure these gangs build does leave traces, and investigators (a mix of City of London Police’s DCPCU, bank fraud teams, and private forensic consultancies) have developed a reasonably consistent playbook for tracing it.

    Domain registration patterns are the first thread to pull. WHOIS privacy is now default on most registrars, but the registration timestamp relative to the attack, the registrar choice, the nameserver configuration, and the IP addresses hosting the fake site and mail server often cluster in ways that match previously documented fraud infrastructure. A lookalike domain registered three days before the fraudulent email was sent, on a Bulgarian shared hosting provider with a nameserver previously linked to phishing campaigns, is a recognisable signature.

    Email header forensics is the second layer. Even when SPF and DKIM pass, the routing path in the received headers tells a story. Legitimate UK solicitor firms typically route through Microsoft 365 or Google Workspace with UK-region data centres. An email routed through a VPS in Frankfurt with a five-hop path before hitting the victim’s inbox stands out when you know what you’re looking for. UK conveyancing fraud email interception attacks frequently show inconsistencies between the mail client declared in headers (e.g. Microsoft Outlook 16) and the actual sending infrastructure, which a forensic analyst can unpick.

    Payment tracing follows the mule account chain. Banks have Suspicious Activity Report obligations under the Proceeds of Crime Act 2002, and Cifas markers on confirmed fraud mule accounts propagate through the shared databases relatively quickly. I’ve written before about how CIFAS and the National Hunter network actually score and flag accounts, and the mule accounts used in conveyancing fraud typically burn fast: opened, used once at volume, then flagged and frozen. The lag is the problem. Fast Payment transfers are cleared in seconds; the freeze comes hours later.

    The domain footprint problem cuts both ways

    One thing that defenders consistently underestimate is how much of the reconnaissance for these attacks is done through entirely legitimate channels. The way publicly accessible data gets aggregated to build targeting profiles applies equally to conveyancing fraud: attackers use the same domain tools, Google index queries, and site crawlers that a legitimate SEO professional would use. UK conveyancing fraud email interception operations routinely involve checking how visible a firm’s email infrastructure is, whether their mail server configuration is exposed, what subdomains resolve publicly, and whether any staff email addresses appear in data breach dumps. That last point is where services that audit what Google and other crawlers can see about your domains, including checking what metadata is publicly indexed, have defensive value. A firm that runs a routine check on its own domain footprint, the kind of thing Search Engine Tuning does for businesses looking at their Google visibility and domain presence, would notice if a lookalike domain appeared in search results or if their MX records were being replicated somewhere unexpected. Keeping your own domain’s SEO and infrastructure signals clean, knowing exactly what a free SEO check reveals about your web presence, is a first-order defensive measure for any firm handling financial transactions.

    The Action Fraud guidance on safe conveyancing now explicitly tells buyers to verify bank details by phone on a number independently sourced, not one from an email. That advice is correct but incomplete. The real fix is at the infrastructure level: solicitor firms need DMARC in enforcement mode (not just reporting), multi-factor authentication on every email account, and a systematic check for lookalike domains registered against their own. Most firms in 2026 still have none of those three in place.

    What the attack surface looks like from the other side

    The UK conveyancing fraud email interception ecosystem is not a disorganised cottage industry. There are specialist groups who sell pre-configured phishing infrastructure: cloned firm websites, configured mail servers, and scripts for the final impersonation emails. There are separate groups who do the reconnaissance and sell target packages. And there are mule account recruiters who operate entirely separately. The division of labour is efficient, and the total cost to run an operation targeting a single transaction is well under £500 against a potential return in the hundreds of thousands.

    The Solicitors Regulation Authority maintains a consumer-facing fraud warning list and has pushed guidance to firms, but enforcement of technical controls remains voluntary. Until DMARC enforcement and domain monitoring become regulatory requirements for conveyancing firms, this attack surface stays wide open.

  • How UK Council CCTV Networks Are Being Stitched Together Into Regional Surveillance Grids: The Software, the Standards, and the Security Gaps

    How UK Council CCTV Networks Are Being Stitched Together Into Regional Surveillance Grids: The Software, the Standards, and the Security Gaps

    There are somewhere north of 5 million CCTV cameras in the UK, and a significant chunk of them belong to local authorities. They hang off lamp posts in town centres, peer down at car parks, watch bus lanes, and stare at parks after dark. Most people walk past them without a second thought. I’ve spent a fair amount of time digging into what actually ties these cameras together, and the picture that emerges is considerably messier, and more exposed, than any council press release would have you believe.

    The phrase “council CCTV network security” sounds dry until you realise what it actually means in practice: thousands of IP cameras, often running outdated firmware, talking over shared network infrastructure to monitoring software that in some cases hasn’t had a meaningful security audit in years. Some of it is stitched into regional sharing agreements that nobody outside a handful of control room operators really understands.

    CCTV cameras mounted on a pole over a wet UK city street, illustrating council CCTV network security concerns
    Photo by Eddie O. on Pexels

    The protocol mess: ONVIF, RTSP, and proprietary nightmares

    The industry settled on ONVIF as the supposed standard for IP camera interoperability back around 2008. On paper, it means any compliant camera can talk to any compliant VMS (Video Management System). In practice, councils have ended up with a patchwork of ONVIF Profile S cameras from Axis, Hanwha, Hikvision, and Dahua sitting alongside older analogue-to-digital encoder units that do their own thing entirely.

    RTSP (Real Time Streaming Protocol) is typically what carries the actual video. The problem is that RTSP authentication is, to put it charitably, inconsistent. Many deployments rely on digest authentication or basic auth passed over the stream URI itself. I’ve seen council procurement documents, obtained via Freedom of Information requests, that explicitly list camera models known to ship with default RTSP credentials that operators are “encouraged” to change. “Encouraged” is doing a lot of heavy lifting there.

    Then there are the proprietary protocols. Milestone XProtect, Genetec Security Center, and IndigoVision Control Center all have their own communication layers on top of the standards. Genetec uses an encrypted proprietary channel between the Archiver and the Directory server, which is fine in principle. But several councils running older Milestone XProtect Essential or Express licences never moved to TLS-secured event streams, meaning camera metadata and motion alerts travel in plaintext across whatever LAN segment the VMS sits on.

    The VMS landscape in UK councils

    From the FoI responses and tender documents I’ve gone through, Milestone XProtect holds a notable share of UK local authority deployments, particularly in smaller district councils that don’t have the budget for enterprise Genetec licences. IndigoVision is popular in Scotland. A handful of major city authorities run bespoke integrations on top of open-source motion detection engines like ZoneMinder, though that brings its own attack surface.

    The regional sharing piece is where it gets genuinely interesting from a security angle. Several police and crime commissioners have pushed “CCTV sharing protocols” where town centre cameras managed by the council feed directly into police control rooms via dedicated MPLS circuits or, increasingly, over IPsec VPN tunnels riding on commercial broadband. The Metropolitan Police’s Project Servator has driven some of this integration in London. Similar regional schemes exist in Greater Manchester, West Yorkshire, and the West Midlands.

    Each integration point is a new attack surface. A VPN tunnel terminated on an unpatched FortiGate or SonicWall at the council end is only as secure as the firmware version running on that box. Given that ransomware groups have already demonstrated an appetite for mapping UK public sector network infrastructure, poorly maintained perimeter devices on council surveillance networks are exactly the kind of low-hanging fruit that gets enumerated during initial access campaigns.

    Server rack and network cables in a dark data centre, representing council CCTV network security infrastructure
    Photo by Brett Sayles on Pexels

    Authentication failures and exposed management interfaces

    Council CCTV network security tends to collapse at the authentication layer. The specific failure modes I keep seeing come up in vulnerability disclosure conversations are predictable once you know where to look.

    First: web management interfaces. Axis cameras, even relatively recent models, expose a web UI on port 80 or 443. If the camera sits on a flat network segment that isn’t properly segmented from the council’s corporate LAN, and many still do, then any machine on that LAN can reach the camera management page. Default credentials (root/pass, admin/admin) persist longer than anyone wants to admit. Shodan has historically indexed exposed Axis and Hikvision interfaces with UK ISP ASNs; some of those are council-owned ranges.

    Second: ONVIF device discovery. ONVIF uses WS-Discovery over UDP multicast (port 3702) to let management systems find cameras automatically. On a properly segmented network this is fine. On a flat /16 that spans multiple council buildings and a shared fibre circuit to the monitoring centre, WS-Discovery packets reach places they absolutely shouldn’t. A device on the guest WiFi that bleeds into the same broadcast domain can enumerate every ONVIF-compliant camera on the segment. I’d point out that this isn’t a theoretical concern; it’s the kind of misconfiguration that shows up in basic Nmap sweeps.

    Third: the VMS server itself. Milestone XProtect Management Server runs on Windows Server and exposes a management client on TCP 8080 (or 443 if configured) plus a mobile server component. Older deployments without current patch levels carry known CVEs, some with public exploit code. The NCSC’s vulnerability disclosure process has fielded reports relating to local authority network infrastructure, though specifics rarely surface publicly.

    The firmware problem nobody wants to fix

    Hikvision and Dahua cameras appear in UK council deployments despite government guidance following security concerns raised about both vendors. The National Cyber Security Centre published guidance in 2023 advising public sector bodies to assess their exposure. By 2026, a non-trivial number of councils still haven’t acted on it, partly because ripping out and replacing installed camera infrastructure costs money that wasn’t in the capital budget, and partly because the procurement officers who bought the kit in 2018 are long gone.

    Firmware update cycles on IP cameras are grim. The cameras go up, they work, and unless something visibly breaks nobody touches them. I’ve spoken to people who work in council IT support and the consistent story is that CCTV infrastructure sits in a grey zone between the IT department (who manage the servers and the network) and the facilities or public safety team (who nominally “own” the cameras). Neither side wants to be responsible for a firmware update that takes twenty cameras offline for an afternoon.

    The NCSC’s video surveillance guidance is actually decent and worth reading if you work anywhere near this stuff. It covers network segmentation, access control, and supply chain considerations. The gap is between the guidance existing and councils having the technical resource to implement it.

    Regional grids and the data aggregation angle

    The surveillance grid framing matters because isolated cameras are a limited risk. What’s changed is the aggregation. Under schemes like the West Midlands Combined Authority’s safety infrastructure work, cameras from multiple council areas feed into shared analytics platforms that do automatic number plate recognition, crowd density monitoring, and in some cases experimental facial recognition pilots that councils have been notably cagey about publicising.

    This is directly adjacent to territory covered in our piece on the national ANPR network and its data retention practices, the infrastructure questions are similar and in some cities the camera networks are literally sharing the same poles and the same fibre backhaul.

    The data that flows through these systems also flows through the organisations maintaining them, and those organisations have varying security postures. A regional aggregation platform that ingests feeds from twelve different councils is only as well-secured as the worst-configured council feeding into it. When digital marketing and public communications teams, who often work with external agencies like dijitul, share infrastructure with surveillance operations on poorly segmented networks, the blast radius of any single compromise grows considerably.

    The fix, in most cases, is not exotic. Network segmentation on a dedicated VLAN with no route to the corporate LAN. Forced password changes on every camera at commissioning, tracked in an asset register. TLS everywhere for management traffic. A firmware patch schedule that someone is actually accountable for. Regular external penetration testing scoped to include the VMS and camera layer, not just the firewalls. These aren’t radical suggestions. They’re the baseline that most councils haven’t reached yet.

    Until councils treat CCTV infrastructure as the networked computing environment it actually is, rather than the passive recording equipment it used to be, the council CCTV network security posture across the UK will remain a soft target sitting in plain sight.

    Frequently Asked Questions

    What protocols do UK council CCTV cameras use to transmit video?

    Most modern IP cameras use RTSP (Real Time Streaming Protocol) to carry video and ONVIF for device management and interoperability. Older installations may use proprietary encoder protocols or analogue-over-coax feeds converted to IP at the recording end. Authentication quality across these protocols varies significantly between deployments.

    What video management software do UK councils typically use?

    Milestone XProtect is common in smaller councils due to its tiered licensing model. Larger authorities often run Genetec Security Center or IndigoVision Control Center. A minority use open-source options like ZoneMinder. The choice of VMS directly affects what attack surface is exposed, since each platform carries its own CVE history and patch cadence.

    How are council CCTV networks connected to police systems?

    Integration typically happens via dedicated MPLS circuits, IPsec VPN tunnels, or in newer deployments, cloud-hosted video sharing platforms. The security of these connections depends heavily on the network device firmware at each end and whether the VPN configuration has been audited. Poorly maintained perimeter devices are a known weak point.

  • Inside UK Fraud Prevention Black Boxes: How CIFAS, National Hunter, and SIRA Actually Score You Before You Get a Bank Account

    Inside UK Fraud Prevention Black Boxes: How CIFAS, National Hunter, and SIRA Actually Score You Before You Get a Bank Account

    You apply for a current account. Everything looks fine on paper. Then comes the rejection with no explanation, no appeal process mentioned, and zero indication of what flagged you. What most people don’t realise is that behind the credit check, before the credit check, actually, there’s a parallel layer of UK fraud prevention databases quietly running your details through scoring logic you’ve never seen and were never told about.

    I’ve spent a fair amount of time pulling apart how these systems work, and honestly it’s one of the murkier corners of UK financial infrastructure. Let me break down the three main players, what data they’re feeding on, and how you can use GDPR to pry your own file open.

    Dark server room representing UK fraud prevention databases running in real time
    Photo by Christina Morillo on Pexels

    The three databases doing most of the heavy lifting

    CIFAS is the one people occasionally hear about. It’s a not-for-profit fraud prevention membership organisation, and its database holds marker records on people who have been identified as either fraudsters or victims of fraud. Members, which include pretty much every major UK bank, building society, insurer, and a growing number of telecoms providers, can query and contribute to it. A CIFAS marker isn’t a credit default. It’s a separate flag entirely, and it persists for six years. If you’re marked as a victim of impersonation, that’s supposed to protect you. If you’re marked for misrepresentation on an application, that’s the career-ending kind.

    National Hunter is less well known and significantly more interesting from a data architecture perspective. Run by Synectics Solutions, it’s specifically designed to detect application fraud by cross-referencing data points across thousands of credit applications. It doesn’t just look at your name and address, it looks at every data field you’ve submitted across every application touched by a member institution. Inconsistencies between applications are what trigger it. Put a slightly different employer name on two applications, use a different middle initial, quote different salary figures to different lenders in the same month, National Hunter logs all of it and scores the discrepancy. The scoring logic is proprietary. Members don’t get a clean decision, they get a risk indicator that tells them to take a closer look.

    SIRA (the Special Investigations Register and its associated National SIRA platform, also run by Synectics) focuses more on insurance fraud, though it’s bled into lending too. It holds records of suspected or proven fraudulent insurance claims, and insurers query it before underwriting. If you’ve had a claim disputed, or if a previous insurer flagged your claim as suspicious even without taking action, there can be a record sitting in there affecting your premiums or outright blocking coverage.

    What data actually feeds these systems

    This is where it gets uncomfortable. The inputs aren’t just things you’ve provided directly. UK fraud prevention databases ingest data from a wide range of sources: your electoral roll presence (or absence), your credit file application history, device fingerprints and IP addresses submitted with online applications, links between addresses and known fraud cases, and relationship graphs between applicants, things like shared addresses, phone numbers, or bank accounts with previously flagged individuals.

    National Hunter in particular builds what amounts to an application history graph. Every time a member queries it, the query itself generates a record. Those query patterns, how many lenders have searched for you, over what timeframe, with what data, become signals in the risk model. A flurry of applications in a short period, even entirely legitimate ones, can push your risk score in a direction that’s hard to recover from without knowing why it moved.

    Terminal screen displaying fraud scoring data from UK fraud prevention databases
    Photo by cottonbro studio on Pexels

    The false positive problem is real and largely unacknowledged. There’s no public data on how often legitimate applicants are incorrectly flagged, because the databases themselves don’t publish that. The CIFAS membership agreement requires institutions to have reasonable grounds before submitting a marker, but “reasonable grounds” is doing a lot of work there. I’d argue the asymmetry is the real issue: it costs an institution almost nothing to submit a marker defensively, but it costs the individual significantly if that marker is wrong. The ICO’s guidance on individual rights under UK GDPR is clear that people have rights here, but exercising them requires knowing the system exists first.

    How the scoring logic actually works (as far as anyone can tell)

    None of the three databases publish their scoring methodology in full, that’s commercially protected. What we do know from subject access requests, ICO enforcement notices, and published court cases involving database markers is this: they’re not binary pass/fail systems. They generate a risk score or flag that the querying institution then weighs alongside their own internal logic.

    National Hunter’s model is particularly opaque. Synectics describes it as a “consistency checking” system, but the reality is that it’s running anomaly detection across a population of millions of applications to produce a relative risk indicator. An application that looks statistically unusual compared to the population baseline gets flagged. What counts as unusual? That’s the bit nobody outside the organisation fully knows. This is relevant context when thinking about how financial institutions use AI-adjacent tools for fraud scoring, for an analysis of where that data pipeline connects to more modern AI security architecture, the team at dijitul.ai covers some of that infrastructure in depth.

    CIFAS markers have defined categories, first-party fraud, third-party fraud, victim of impersonation, facility takeover, and several others, and each has a slightly different impact on how institutions respond. A “victim of impersonation” marker should theoretically trigger protective measures rather than rejection. In practice, some institutions still decline applicants with any kind of CIFAS marker and don’t always distinguish between the categories clearly.

    Using GDPR subject access requests to pull your file

    This is the part most people skip, and they shouldn’t. All three databases are data controllers under UK GDPR, which means you have a right to request all personal data they hold on you. A Subject Access Request (SAR) costs nothing, must be responded to within 30 days, and if they hold data on you, they have to give it to you.

    The trick is knowing where to send them. For CIFAS, you submit directly via their online portal or by post to their data subject team. For National Hunter and SIRA, you go through Synectics Solutions. Their contact details are published, though not exactly prominently. Send a clear written request identifying yourself (full name, date of birth, current address, and a couple of previous addresses) and state that you’re making a subject access request under Article 15 of UK GDPR.

    What you get back varies. CIFAS will tell you whether a marker exists, what category it is, and which member submitted it, though not always the full reasoning behind the submission. National Hunter returns a summary of the application history records they hold, which is often eye-opening: you’ll see every institution that’s queried your details, when, and with what data fields. SIRA returns insurance-linked records if they exist.

    If you find an error, a marker submitted incorrectly, a record with wrong data, or a case of mistaken identity, you have the right to request rectification or erasure under UK GDPR. If the database or the submitting member refuses, escalate to the ICO. It’s a slow process, but there are documented cases where incorrect CIFAS markers have been successfully challenged and removed.

    The surveillance architecture you didn’t consent to

    What’s worth sitting with is the scale of this. Every UK bank account application, mortgage, loan, credit card, and most insurance policies now run through at least one of these databases in real time. The data being ingested goes well beyond what you knowingly submitted. Device identifiers, behavioural signals, network connections between individuals, it’s a surveillance graph with direct financial consequences, run by private organisations with minimal public accountability.

    For context, the same kind of hidden data pipeline problem shows up in other parts of UK infrastructure. The way crypto drainer scams disguise themselves as FCA-registered platforms exploits exactly this opacity, people don’t know what the legitimate data flow looks like, so they can’t spot the fake. And the NCSC’s vulnerability disclosure process faces the same institutional inertia when researchers try to surface problems in opaque systems that institutions have little incentive to acknowledge publicly.

    My take: the UK fraud prevention database ecosystem does a real job. Fraud costs UK consumers and businesses billions a year, and cross-institution data sharing genuinely helps catch organised fraud rings that individual lenders would never detect alone. But the current setup has next to no transparency, inadequate error correction, and meaningful real-world harm when it goes wrong. Pull your SAR files. Know what’s in there. Don’t assume a clean credit file means you’re clear.

    Frequently Asked Questions

    What is CIFAS and how do I know if I have a marker?

    CIFAS is a UK fraud prevention membership organisation that holds a shared database of fraud markers submitted by banks, insurers, and other lenders. You can find out whether you have a marker by submitting a Subject Access Request directly to CIFAS via their website, it’s free and they must respond within 30 days under UK GDPR.

    How does National Hunter differ from a standard credit check?

    A credit check pulls your financial history from credit reference agencies like Experian or Equifax. National Hunter is a separate system that checks for inconsistencies across multiple credit and loan applications you’ve made, looking for discrepancies in the data you’ve submitted to different lenders. A clean credit file doesn’t mean you’re clear on National Hunter.

    Can a fraud database marker stop me getting a bank account?

    Yes. A CIFAS or National Hunter flag can lead a bank to decline an application without explaining why in detail. Victim-of-impersonation markers are supposed to trigger protective measures rather than outright refusal, but some institutions treat any marker as grounds for rejection. If you believe you’ve been incorrectly marked, you can challenge this through the relevant database’s dispute process and escalate to the ICO.

    How do I submit a Subject Access Request to SIRA or National Hunter?

    Both SIRA and National Hunter are operated by Synectics Solutions. Send a written Subject Access Request to Synectics, including your full name, date of birth, current address, and a couple of previous addresses, stating you’re requesting all personal data under Article 15 of UK GDPR. They must respond within 30 days at no cost to you.

    What can I do if my fraud database record contains incorrect information?

    Under UK GDPR you have the right to request rectification of inaccurate data. Contact the database operator and the institution that submitted the record, explaining the error with any supporting evidence. If they refuse to correct it, you can lodge a complaint with the Information Commissioner’s Office (ICO), which has enforcement powers over all three databases.

  • CAN Bus Hacking in 2026: How UK Researchers Are Exposing the Attack Surface Inside Modern Cars

    CAN Bus Hacking in 2026: How UK Researchers Are Exposing the Attack Surface Inside Modern Cars

    Modern cars are computers that happen to have wheels. That’s been true for a while, but the attack surface in 2026 is genuinely alarming, dozens of ECUs, telematics boxes, Bluetooth stacks, LTE modems, and a single shared bus topology that was designed in the 1980s when nobody thought a vehicle would ever be network-connected. I’ve been watching UK security researchers dig into this space for the last couple of years, and the findings are uncomfortable reading for manufacturers, regulators, and anyone who owns a relatively recent car sold on British roads.

    OBD-II port under dashboard used in CAN bus hacking research
    Photo by Daniel Andraski on Pexels

    What the CAN bus actually is and why it’s a problem

    The Controller Area Network (CAN) protocol was developed by Bosch in 1983 and standardised as ISO 11898. It lets microcontrollers inside a vehicle talk to each other without a host computer in the middle. Your engine management unit, your ABS controller, your dashboard cluster, your steering column, they all broadcast short frames onto the same wire, and every node on the bus reads every frame. There’s no authentication. There’s no encryption. Any node can spoof any other node. The original assumption was physical isolation: if you’re inside the car and on the bus, you’re trusted.

    That assumption collapsed the moment vehicles got OBD-II ports (mandatory on UK petrol cars from 2001 under EU regulations, now retained under UNECE type-approval rules carried over into UK law post-Brexit), Bluetooth dongles, Wi-Fi hotspots, and over-the-air update channels. The bus is still the same fundamentally insecure topology, but now there are bridges from the outside world straight onto it. That’s CAN bus hacking in its simplest framing: you find a path to the bus, and then you own every node on it.

    OBD-II port exploitation: the hole under your dashboard

    The OBD-II port is the easiest entry point. It’s physically accessible, it’s mandated by law, and it connects directly to the CAN bus. Mechanics use it. MOT testers use it. Insurance telematics boxes plug into it. So do a huge number of cheap Bluetooth and 4G dongles sold on the high street and via marketplaces like Amazon UK.

    Security researcher Ken Munro at Pen Test Partners (a Buckinghamshire-based firm that has done some of the most serious vehicle security work in the UK) has demonstrated repeatedly that poorly secured OBD dongles can be compromised over Bluetooth from outside the vehicle. Once you have a shell on the dongle, you’re issuing raw CAN frames. At that point you can spoof sensor readings, suppress fault codes, or in more serious cases, influence safety-critical systems depending on the vehicle architecture. The research has been published openly, and the NCSC has referenced this class of attack in its guidance on connected vehicle security.

    What makes this worse in 2026 is the secondhand market. Cars change hands, but the telematics box the previous owner used for cheaper insurance often stays plugged in. I’ve seen three separate threads on UK automotive forums where buyers found active insurance dongles still live and broadcasting on a car they’d just bought. That’s an attacker’s dream: a persistent, internet-connected bridge to the CAN bus, and the current owner doesn’t even know it’s there.

    Over-the-air update interception and firmware integrity

    OTA updates are where things get genuinely interesting. Every mainstream manufacturer now pushes firmware updates to ECUs wirelessly. Tesla has done it longest, but Ford, BMW, Volkswagen Group, and Stellantis brands are all doing it on models sold in the UK. The update mechanism typically involves a telematics control unit (TCU) with an LTE modem that pulls a signed firmware image from a manufacturer’s backend, verifies a signature, and then flashes the target ECU over the internal bus.

    The signing is usually RSA or ECDSA, and when it’s implemented properly, intercepting the download gives you an encrypted blob you can’t do much with. The problem is implementation. Researchers at the University of Birmingham published work in 2023 demonstrating that several manufacturers’ TCUs would accept updates over unencrypted HTTP under specific fallback conditions, and that certificate pinning was either absent or bypassable with a compromised root CA. A man-in-the-middle on the vehicle’s Wi-Fi or a rogue 4G cell (a cheap software-defined radio setup can fake a cell tower well enough to catch an LTE data session) puts an attacker in a position to serve a malicious firmware image, provided they can also forge or strip the signature check.

    UK UNECE Regulation 156, which covers software update processes and has been legally binding on new UK type-approvals since 2022, requires manufacturers to document their software update management systems and have them audited. It does not specify cryptographic standards in granular detail. That gap is where researchers are finding the interesting stuff.

    Reverse engineering proprietary firmware with open-source tools

    Getting firmware off an ECU is a prerequisite for most serious research. The common approaches in the UK security community right now involve JTAG and SWD debugging interfaces (often physically present on the PCB but with fuses blown or debug-lock bits set), flash chip extraction using a hot-air rework station and an SP flash programmer, and occasionally exploiting bootloader vulnerabilities to dump memory over an existing interface like the CAN bus itself via diagnostic protocols (UDS on ISO 14229).

    Once you have a binary, the toolchain looks familiar to anyone who does embedded reverse engineering. Ghidra (the NSA-released disassembler, now widely used by UK researchers) handles most architectures you’ll find in automotive ECUs, Renesas RH850, Infineon TriCore, NXP S32. Binwalk identifies filesystem structures. Custom Python scripts parse proprietary calibration maps. The ECU remapping community has actually done a huge amount of groundwork here: people who tune engines for performance have been extracting and modifying ECU firmware for years, and their tooling overlaps significantly with what security researchers use. Sites like fastandfurious4.co.uk sit squarely in the performance car world where ECU remapping is part of the culture, and that culture has produced engineers who understand firmware internals better than most professional security teams do.

    The open-source tool getting the most attention right now is OpenXC combined with python-can, which lets researchers log and replay CAN frames cheaply using a Raspberry Pi and a MCP2515 module (total hardware cost: under £20 from any UK electronics supplier). Couple that with CANalyze or SavvyCAN for traffic analysis, and you have a working lab for CAN bus research. The barrier to entry is genuinely low, which is both democratising for legitimate researchers and concerning for threat actors.

    For context on how physical infrastructure security intersects with digital systems in UK transport, it’s worth reading about how smart motorway speed limits interact with connected car systems, because variable speed enforcement increasingly relies on data from the vehicles themselves, creating feedback loops that don’t exist in traditional road infrastructure.

    The regulatory picture and where UK researchers fit in

    UNECE Regulation 155 (cybersecurity management systems) and Regulation 156 (software updates) are the backbone of vehicle cybersecurity law for new UK type-approvals. The Vehicle Certification Agency handles type-approval in Great Britain. These regulations require manufacturers to maintain a cybersecurity management system throughout the vehicle lifecycle, conduct threat analysis and risk assessments (TARA), and monitor for new threats post-production. In practice, the auditing is paper-heavy and the monitoring is largely self-reported.

    UK researchers who find vulnerabilities face the same disclosure problem that exists across the industry. There’s no equivalent of the NCSC’s coordinated vulnerability disclosure process for automotive systems, which is already imperfect for software infrastructure, and manufacturers’ own disclosure programmes are inconsistent. Some pay bounties. Some send legal letters. The UK’s cybercrime reporting infrastructure is not designed for this class of finding. So most serious automotive research ends up going through academic channels, conference papers (Escar Europe is the main venue), or via firms like Pen Test Partners who have the manufacturer relationships to get findings acted on.

    The Vehicle Technology and Aviation Bill (currently in parliamentary committee as of mid-2026) touches on automated vehicle liability but is largely silent on active cybersecurity obligations for existing vehicles. The gap between what UNECE 155/156 requires on paper and what actually gets tested on production hardware is significant, and the UK security research community is filling it faster than the regulator is.

    My read on where this goes: the attack surface gets worse before it gets better. More connectivity, more OTA updates, more third-party apps and dongles, same underlying CAN topology. Vehicle-to-everything (V2X) communication, which UK trials are already running on the A2 and M25 corridors, adds another radio interface to the mix. The researchers doing this work, often working from homelabs with sub-£100 hardware, are the reason any of this gets fixed at all. The pattern of researchers finding what institutional security misses is consistent across every technical domain. Automotive is no different.

    The NCSC’s connected vehicle security guidance is publicly available at ncsc.gov.uk and worth reading if you want the official framing, even if the practical reality in 2026 is considerably messier than the guidance implies.

    Frequently Asked Questions

    What is CAN bus hacking and how does it work on modern cars?

    CAN bus hacking exploits the Controller Area Network, the internal communications protocol that lets ECUs inside a vehicle talk to each other. Because the protocol has no authentication or encryption, anyone with access to the bus, via the OBD-II port, a compromised telematics dongle, or an OTA update channel, can read all traffic and inject spoofed frames that other nodes will act on.

    Is accessing a car's CAN bus via the OBD-II port legal in the UK?

    Plugging into your own car’s OBD-II port is legal. Using that access to interfere with vehicle systems in a way that makes the car unsafe or to commit fraud is a criminal offence under the Computer Misuse Act 1990 and road traffic legislation. Security researchers working on vehicles they own, or with explicit owner consent, occupy a legally grey but generally accepted space provided they disclose responsibly.

    Can over-the-air updates be intercepted to push malicious firmware to a car?

    In theory, yes, and researchers have demonstrated it in controlled conditions. Properly implemented OTA systems use cryptographically signed firmware that an ECU will verify before flashing. The risk lies in weak implementations: absent certificate pinning, unencrypted fallback channels, or signature verification that can be bypassed. UNECE Regulation 156 requires manufacturers to document their update security, but independent testing of production systems is limited.

    What tools do UK researchers use to analyse CAN bus traffic?

    Common tools include python-can and SavvyCAN for logging and replaying CAN frames, a Raspberry Pi with an MCP2515 module as cheap hardware, and Ghidra for firmware reverse engineering once a binary has been extracted. Total hardware cost for a basic CAN research setup is under £20. More advanced work involves JTAG extraction and UDS/ISO 14229 diagnostic protocol fuzzing.

  • Crypto Drainers Targeting UK Investors: How Wallet-Emptying Smart Contracts Are Being Disguised as HMRC Tax Tools and FCA-Registered Platforms

    Crypto Drainers Targeting UK Investors: How Wallet-Emptying Smart Contracts Are Being Disguised as HMRC Tax Tools and FCA-Registered Platforms

    There’s a particular breed of scam doing the rounds right now that I find genuinely impressive in how nasty it is. Not admirable, to be clear. But the engineering is sharp, the social engineering sharper, and the targets are ordinary British retail investors who’ve done everything right, declared their crypto, tried to stay compliant, and got robbed anyway. The crypto drainer scam UK HMRC FCA combo is the current peak of that particular racket, and it’s worth understanding exactly how it works.

    Anonymous hacker figure at monitors in a crypto drainer scam UK HMRC FCA campaign setup
    Photo by Sora Shimazaki on Pexels

    What a crypto drainer actually is

    A drainer isn’t a phishing page that steals your seed phrase. That’s old-school. A drainer is a malicious smart contract, usually deployed on Ethereum or a cheap EVM-compatible chain like Base or Polygon, that you authorise yourself. One transaction. One signature. Everything gone.

    The flow is simple in concept. The attacker deploys a contract with a function that calls transferFrom on every ERC-20 token in your wallet, plus sweeps native ETH, once you’ve granted approval. The contract often bundles these into a single multicall so the drain completes atomically. If you sign the approval, the contract does the rest without any further input from you or the attacker. Etherscan will cheerfully show you the transaction you authorised. The funds are gone in seconds, typically bridged and tumbled within minutes.

    Drainer kits, pre-built, ready to deploy, have been selling on Telegram and dark web forums since at least 2023. By 2026, they’re subscription services. Some charge a flat monthly fee; others take 20–30% of everything drained. There are support channels, changelogs, even feature requests. It’s a genuinely functional criminal SaaS ecosystem.

    The HMRC angle: why it’s so effective against UK investors

    Here’s where it gets specifically British. HMRC treats crypto as a capital asset, which means UK retail investors have real, ongoing tax obligations, capital gains on disposals, income tax on staking rewards, and a Self Assessment deadline that makes people anxious every January. That anxiety is the attack surface.

    The campaigns I’ve been tracking follow a consistent pattern. A UK investor searches for something like “HMRC crypto tax calculator 2025-26” or “how to report crypto gains UK”. They land on a site that looks like a professional tax tool, clean UI, GOV.UK-adjacent colour scheme, the HMRC logo (lifted directly, obviously), and a table showing allowances and rates that are actually accurate. The accuracy matters. It builds trust.

    Then comes the hook. To generate your “personalised tax report” or “portfolio gain summary”, the tool asks you to connect your wallet. This is framed as read-only, just so the tool can see your holdings and calculate gains automatically. That framing is a lie. The wallet-connect flow that follows requests a signature that isn’t read-only at all. It’s an approval transaction, or in some cases a permit signature (EIP-2612), which requires no on-chain transaction from you, just an off-chain signature that the drainer contract can then use to pull funds.

    Spoofed FCA registration numbers

    The second layer of the crypto drainer scam UK FCA attack is spoofing the Financial Conduct Authority’s register. This one is brazen. The FCA’s Financial Services Register is public, anyone can look up a firm’s registration number at register.fca.org.uk. Attackers take real FCA registration numbers from legitimate, inactive, or recently dissolved crypto asset firms and paste them onto their fake platforms.

    Most retail investors don’t verify these properly. They see “FCA Registered: 123456” in the footer, search that number, find a result on the FCA register, and stop there. They don’t check whether the firm name matches, whether the registration covers the specific activity advertised, or whether the firm is listed as “Cancelled” or “Removed”. The FCA register UI doesn’t exactly make this obvious at a glance.

    I’ve seen at least three campaigns in 2026 using registration numbers belonging to firms that surrendered their authorisation, meaning the number exists in the register but the firm is no longer permitted to operate. Technically accurate enough to pass a quick look. Technically fraudulent in every meaningful sense.

    The FCA does maintain a Warning List of known unauthorised firms, and some of these drainer sites do end up there eventually. But the campaigns burn through domains fast, similar to how UK phishing infrastructure rotates through .uk and .co.uk domains before takedown catches up. A site lives for a week, drains a few wallets, disappears.

    The wallet-connect flow in technical detail

    Let’s get into the mechanics, because understanding this is the only real defence.

    When a legitimate DeFi protocol uses WalletConnect or a browser wallet like MetaMask, it sends a JSON-RPC request to your wallet asking for a signature or transaction approval. The wallet UI shows you what you’re signing. The problem is that most users have been trained to click through these prompts, and drainer sites exploit that conditioning brutally.

    The specific techniques vary. Some drainers request eth_sign on arbitrary data, which some wallet implementations will sign without showing readable context. Others use personal_sign with a blob that looks like a random hash but is actually a structured message that the contract can verify on-chain. The most sophisticated use EIP-712 typed data signing, which does show structured fields in the wallet UI, but labels them with innocuous names like “TaxReport”, “PortfolioID”, or “ConsentHash”.

    The permit approach is particularly nasty because it leaves no on-chain trace until the attacker redeems the signature. You sign something off-chain, nothing happens immediately, and you walk away thinking the tool just didn’t work. Then, hours later, the attacker submits the permit transaction and the drain executes. By the time you notice, the transaction trail has been routed through a mixer.

    This connects to a broader pattern of how credential and approval theft works across the UK attack surface, similar social engineering mechanics appear in SIM swap fraud targeting UK banking 2FA, where the goal is always to get the victim to perform a legitimate action that completes the attacker’s objective.

    Why victims can’t easily get their money back

    This is the part that really stings. Crypto transactions are irreversible by design. There’s no equivalent of a bank chargeback, no Section 75 protection, no FSCS coverage. If you signed the transaction, you signed it. The contract executed correctly from the blockchain’s perspective.

    Action Fraud will take your report. What happens next is, let’s say, not exactly rapid. The NFIB system processes crypto fraud reports but chain analysis and cross-border coordination make recovery genuinely rare. The National Cyber Security Centre has published guidance on crypto scams, but prevention messaging doesn’t help people who’ve already lost funds.

    Some victims have had partial success contacting exchanges where drained funds were cashed out, if the attacker made the mistake of using a KYC’d exchange, a police production order can sometimes freeze an account. But drainer operators are rarely that careless. Funds typically hit a bridge, then a DEX swap, then a privacy protocol, within one automated script execution.

    How to spot and avoid these drainer campaigns

    A few concrete things that will actually help. First: no legitimate HMRC tool, tax calculator, or GOV.UK service will ever ask you to connect a crypto wallet. Ever. HMRC calculates tax from figures you provide, not by reading your wallet directly. If something is asking for a wallet connection in a tax context, it’s a drainer. Full stop.

    Second: check FCA registrations properly. Don’t just search the number. Verify the firm name matches exactly, check the registration status is “Authorised” (not Cancelled or Removed), and check that the specific permission listed covers what the site claims to do. Crypto asset firms registered under the Money Laundering Regulations have a separate register entry from those with full FCA authorisation, and the distinction matters.

    Third: read wallet prompts. Actually read them. MetaMask and most modern wallets now flag high-risk signature types. If you see a warning about unlimited token approvals or permit signatures, stop. No tax tool needs that.

    Fourth: use a hardware wallet for anything significant. Ledger and Trezor devices display the full transaction data on a separate screen, much harder to slip malicious approval requests past a user who’s looking at a physical device rather than a browser popup.

    The NCSC’s vulnerability disclosure and threat intelligence functions are increasingly aware of drainer campaigns, similar to the infrastructure monitoring described in the GCHQ NCSC disclosure process, but drainer sites move faster than takedown processes. The defence has to start with the individual. Know what you’re signing.

    Frequently Asked Questions

    What is a crypto drainer and how is it different from regular phishing?

    A crypto drainer is a malicious smart contract that empties your wallet after you sign a single approval transaction. Unlike phishing, which steals your seed phrase or password, a drainer works entirely through legitimate blockchain mechanics, you authorise it yourself, which is why it’s so hard to reverse or dispute.

    Are fake HMRC crypto tax calculator sites easy to spot?

    Not always, which is the problem. The better-built ones use accurate tax rates, credible-looking GOV.UK-style design, and real HMRC logos. The giveaway is the wallet-connect requirement, no genuine HMRC or tax tool will ever ask you to connect a crypto wallet to calculate your gains.

    How do I check if an FCA registration number is legitimate?

    Go directly to register.fca.org.uk and search the number. Check that the firm name on the register exactly matches the site you’re looking at, that the status shows ‘Authorised’ (not Cancelled or Removed), and that the specific permissions listed cover what the platform claims to do. Mismatches on any of these are red flags.

    Can I get my money back if a crypto drainer steals my funds?

    Realistically, recovery is very rare. Crypto transactions are irreversible and there’s no FSCS protection or chargeback mechanism. You can report to Action Fraud and the FCA, and in some cases police can freeze exchange accounts via production orders if the attacker used KYC’d platforms, but most drainer operators route funds through mixers and DEX swaps within minutes.

    What wallet settings or tools can protect me from drainer attacks?

    Use a hardware wallet like Ledger or Trezor for any significant holdings, they display full transaction details on a separate screen. In MetaMask, pay attention to approval warnings and never grant unlimited token approvals to unfamiliar contracts. Browser extensions like Revoke.cash let you audit and revoke existing approvals that you may have granted previously.

  • Inside GCHQ’s NCSC Vulnerability Disclosure Process: What Actually Happens When a Researcher Reports a Critical UK Infrastructure Bug

    Inside GCHQ’s NCSC Vulnerability Disclosure Process: What Actually Happens When a Researcher Reports a Critical UK Infrastructure Bug

    You’ve found something. A memory corruption bug in software running across NHS trusts, or an authentication bypass in a platform used by three government departments. You’ve documented it, written a clean proof-of-concept, and you’re sitting there wondering whether to report it through official channels or just post it on a forum and watch the chaos unfold. If you go the responsible route and report to the NCSC, here’s what actually happens, because the official documentation paints a tidy picture that doesn’t quite match what researchers describe on the other side.

    Researcher in dark room reviewing code related to NCSC vulnerability disclosure UK process
    Photo by Rafael Minguet Delgado on Pexels

    The NCSC’s coordinated vulnerability disclosure framework, explained

    The NCSC operates the UK’s central coordinated vulnerability disclosure (CVD) process, sitting underneath GCHQ in Cheltenham. The framework is modelled loosely on international standards, ISO/IEC 29147 for disclosure and 30111 for handling, but adapted for the UK’s specific mix of government systems, critical national infrastructure, and private sector tech. The idea is straightforward: researcher finds bug, researcher reports to NCSC, NCSC contacts the affected vendor or department, everyone agrees a remediation timeline, and a public advisory goes out once a patch exists. Clean. Orderly. In theory.

    The NCSC’s vulnerability reporting page gives you an online submission form plus a PGP key for encrypted reports. You can also email them directly. First contact is supposed to trigger an acknowledgement within two working days, and from what I’ve seen, they’re pretty consistent on that front. The triage team reads what you’ve sent, assesses severity using CVSS scoring alongside their own contextual weighting (whether the affected system is CNI, how exploitable it is in the wild, whether there’s active threat actor interest), and then decides who owns the fix.

    What the triage process actually looks like

    Here’s where it gets interesting. The NCSC doesn’t fix anything itself. It acts as a broker between the researcher and whoever built or operates the vulnerable system. If you’ve found a bug in a vendor’s product, say, a popular enterprise VPN client used across the public sector, the NCSC will contact that vendor and attempt to coordinate a fix timeline. If you’ve found something in a government-owned system, the process routes internally, sometimes through the Cabinet Office or the relevant department’s own technical security team.

    The target remediation window is 90 days. That’s not a hard deadline in law, but it’s the standard the NCSC applies before considering whether to advise on limited public disclosure. Some researchers I’ve spoken to say the 90-day window is generally respected, especially for high-severity findings. Others describe situations where a government department has essentially stonewalled the process, citing operational constraints, procurement cycles, or, and this comes up more than you’d expect, the fact that fixing the vulnerable component would require replacing an entire legacy system they don’t have budget to touch.

    Where the process breaks down

    The biggest friction point isn’t the NCSC itself, most researchers say the team is technically competent and genuinely motivated. The problem is the handoff. Once the NCSC contacts an affected department or vendor, the researcher is largely cut out of the loop. You submit your report, get a case reference, and then wait. The NCSC won’t necessarily tell you what the vendor said, whether they’ve accepted the severity rating, or what the remediation plan looks like. That opacity is deliberate, the NCSC is trying to keep lines of communication open with vendors, and looping a researcher into every exchange would complicate that, but from the researcher’s side it can feel like your report vanished into a void.

    This connects to a broader concern about legacy infrastructure. The same class of problems we’ve seen with ransomware groups mapping UK critical national infrastructure, outdated systems, fragmented ownership, no clear party responsible for patching, makes the CVD process genuinely hard to execute. When you can’t identify a single responsible vendor or department for a vulnerability, the broker model struggles. The NCSC has to work out whether it’s talking to a network operator, a software supplier, a managed service provider, or some combination of all three. That takes time, and the 90-day window starts ticking regardless.

    There’s also the question of what counts as a government vulnerability versus a vendor vulnerability. Take something like a misconfigured API endpoint leaking data from a government-contracted SaaS platform. The department didn’t write the code; the vendor is based overseas; the data belongs to UK citizens. Who’s responsible? The NCSC will attempt to coordinate, but it has no legal enforcement power over a foreign vendor. It can apply reputational pressure, escalate to international CERT partners, or advise the department to terminate the contract, but it can’t compel a fix on any timeline.

    The researcher experience: what people actually say

    Bug bounty hunters and independent researchers who’ve gone through the NCSC process have mixed views. The positive feedback clusters around transparency in initial communication, the quality of the triage team’s technical responses, and the fact that the NCSC does issue public advisories when vendors cooperate. The NCSC’s own published advisories are detailed and useful, they’re worth bookmarking if you’re tracking vulnerabilities in UK-deployed software.

    The negative feedback centres on a few recurring themes. One is the absence of bug bounty payments. The NCSC doesn’t pay for vulnerability reports. Full stop. If you’ve spent three weeks reverse-engineering a binary to find a critical flaw in a system protecting public sector data, your reward is a thank-you and a credit in an advisory, if you get even that. Several researchers have told me they’ve moved away from reporting UK government findings to the NCSC because the economics don’t work. They’ll report vendor bugs through the vendor’s own programme where there’s money attached, and only escalate to the NCSC when the vendor ignores them.

    A second issue is status updates. Once your report is in, you might get silence for weeks. The NCSC says it will update researchers on “significant developments”, but significant is doing a lot of work in that sentence. Researchers who’ve reported high-severity bugs describe waiting 40 or 50 days without meaningful updates, unsure whether the vendor is actively patching or has simply deprioritised the finding. This is similar to frustrations documented around other reporting systems, the kind of opacity that also plagues Action Fraud’s NFIB triage process, where reports go in and nothing tangible seems to come out.

    When the NCSC goes public without a patch

    The nuclear option in CVD is publishing a vulnerability advisory before a patch exists. The NCSC will do this, they say so explicitly, if the 90-day window passes without meaningful remediation progress, or if they assess that the vulnerability is already being actively exploited in the wild. In practice, this is rare but it does happen. The NCSC’s vulnerability advisories page carries notices where vendors are named alongside unfixed issues, which creates real commercial and reputational pressure.

    What researchers want is more transparency about how this decision gets made. The NCSC’s public guidance doesn’t specify exactly what threshold triggers forced disclosure. That ambiguity is probably intentional, rigid rules would let vendors game the timeline, but it leaves researchers uncertain about whether their 90-day clock will actually result in disclosure or quietly extend because the affected system is deemed too sensitive to expose publicly. The tension is sharpest around government-operated systems. Disclosing an unpatched vulnerability in, say, infrastructure touching national security would be handled very differently from disclosing one in a third-party vendor’s product.

    What a better process might look like

    A few things would genuinely improve the experience without blowing up the framework. Regular status pings to researchers, even automated ones saying “still in remediation, no change”, would cut the anxiety. Some form of recognition or modest financial acknowledgement for critical findings would bring more serious researchers into the official channel rather than pushing them toward private markets or full disclosure. And clearer published criteria for when the NCSC escalates to forced disclosure would make the 90-day window feel like an actual commitment rather than a rough guide.

    I’d also argue the NCSC could learn something from how the open disclosure community handles complex multi-party vulnerabilities, the kind of coordination issues that show up when, for instance, a single library flaw affects dozens of systems simultaneously. The leaky public repositories problem across NHS and government GitHub accounts is a good example: multiple responsible parties, unclear ownership, and a finding that’s already semi-public by the time anyone reports it formally. The NCSC’s CVD framework wasn’t really designed for that shape of vulnerability, and it shows.

    The framework is worth engaging with. The team is capable and the process, when it works, does result in patches and public advisories that protect real systems. But it’s not the smooth machine the official documentation implies. Go in with realistic expectations, document everything you send, and don’t hold your breath waiting for updates. The bugs you find matter, just don’t expect the process to feel like it knows that.

    Frequently Asked Questions

    How do I report a vulnerability to the NCSC in the UK?

    You can submit a report via the NCSC’s online vulnerability reporting form at ncsc.gov.uk, or email them directly using their published PGP key for encrypted submissions. You should receive an acknowledgement within two working days, along with a case reference number.

    Does the NCSC pay bug bounties for vulnerability reports?

    No. The NCSC does not pay financial rewards for vulnerability disclosures. Researchers may receive credit in a published advisory, but there is no bounty programme. Many researchers report this as a significant barrier to engaging with the official process.

    How long does the NCSC vulnerability disclosure process take?

    The NCSC targets a 90-day remediation window from the point of reporting. In practice, timelines vary considerably depending on the vendor’s responsiveness, the complexity of the fix, and whether the affected system is government-operated. Researchers have reported waits well beyond 90 days without resolution.

  • Inside the UK’s Cybercrime Reporting Black Hole: How Action Fraud’s NFIB System Processes, Triages, and Quietly Buries Your Report

    Inside the UK’s Cybercrime Reporting Black Hole: How Action Fraud’s NFIB System Processes, Triages, and Quietly Buries Your Report

    Every year, hundreds of thousands of people in Britain report being scammed, hacked, or defrauded. They type their details into the Action Fraud portal, click submit, and then… nothing. Maybe an automated email arrives. Maybe a crime reference number. And then silence. I’ve spoken to people who waited eighteen months without a follow-up, people who lost five-figure sums and heard nothing more than a bot acknowledgement. So what is actually happening on the other side of that form? Where does the report go, and why does it so rarely result in anyone being nicked?

    This is a forensic look at the operational and technical pipeline behind Action Fraud and the National Fraud Intelligence Bureau, the NFIB. Understanding Action Fraud NFIB how it works in practice, rather than how the press releases describe it, is genuinely illuminating. And more than a little grim.

    Dark server room representing the Action Fraud NFIB data processing infrastructure for UK cybercrime reporting
    Photo by panumas nikhomkhai on Pexels

    The intake layer: what happens when you submit a report

    Action Fraud is not a police force. That distinction matters more than most people realise. It is operated by the City of London Police under contract, functioning essentially as a national reporting centre. When you file a report through the Action Fraud website or call 0300 123 2040, your data lands in a system called NFIRS, the National Fraud Intelligence Reporting System, which feeds directly into the NFIB’s analysis infrastructure.

    The intake form captures a fairly detailed picture: the type of fraud (there are over 60 sub-categories), dates, monetary loss, suspect details, communication records, and any supporting evidence you upload. Here’s where the first structural problem sits. The quality of what goes in is wildly inconsistent. A technically literate victim might submit server logs, email headers, and a detailed timeline. Someone’s nan who got scammed by a fake parcel delivery text submits “he sounded foreign.” Both go into the same queue and get processed through the same scoring engine.

    NFIB’s intelligence triage: the scoring model that decides your fate

    The NFIB is where actual analysis supposedly happens. Staffed by a mix of civilian intelligence analysts and City of London Police officers, the bureau runs incoming reports through an automated scoring and clustering model before any human eyeballs touch the data.

    The scoring model prioritises reports based on several weighted factors. Monetary value is the most obvious one; a £50,000 investment fraud scores significantly higher than a £200 purchase scam. But the system also looks for what NFIB calls “linkage”, whether a report connects to suspects, phone numbers, bank accounts, or IP addresses already appearing in other reports. This is where the intelligence value actually lives. A single phone number appearing in 400 separate fraud reports is vastly more actionable than 400 isolated incidents.

    The clustering algorithm groups reports by shared indicators of compromise: sort codes, mobile numbers, email domains, IBAN structures, and increasingly, device fingerprints and IP ranges. When a cluster hits a threshold, it nominally triggers escalation to what the NFIB calls a “develop” package, a compiled intelligence package ready for dissemination to a police force. The operative word there is “nominally.”

    Why the majority of reports go nowhere

    Here is the uncomfortable arithmetic. According to data published by the City of London Police and analysed by BBC News, fewer than 1 in 30 fraud reports submitted to Action Fraud results in a charge or summons. Some estimates put the actual investigation rate even lower. The NFIB can only disseminate so many packages, and forces receiving those packages are under no obligation to act on them. A regional force with three economic crime detectives covering an entire county is not going to prioritise a medium-value online fraud when they’re also managing knife crime and county lines.

    The triage scoring model itself creates a structural exclusion zone. Reports below a certain monetary threshold, roughly £1,000 in most cases, are unlikely to generate the kind of linkage data that pushes a cluster into actionable territory quickly enough. They still count toward statistics. They still generate a crime reference number. But in practice, they sit in a database accruing dust unless a future, higher-value report links back to the same suspect infrastructure. I’d argue this is intentional design rather than a bug: the system is optimised to surface organised fraud groups, not to give individual victims any real resolution.

    There’s a parallel worth drawing here. The way NFIB clusters and scores fraud intelligence isn’t entirely unlike how the FCA’s RegTech surveillance pipelines monitor financial markets for manipulation patterns. Both systems look for anomalies across massive data sets and deprioritise low-volume individual signals. The difference is that the FCA’s system has teeth. NFIB’s output depends entirely on under-resourced regional forces choosing to act.

    How data flows to regional forces

    When NFIB decides a cluster is worth packaging, the output goes into what they call an Intelligence Development Package or IDP. This is essentially a structured intelligence product: suspect profiles, linked bank accounts, phone number analysis, victim geography, and a recommended force for action based on suspect or banking location.

    The routing logic for IDPs is fairly straightforward. If suspect bank account details resolve to a branch in West Yorkshire, the package goes to West Yorkshire Police’s economic crime unit. If the fraud infrastructure spans multiple force areas, which is common with organised groups, the package might go to Regional Organised Crime Units (ROCUs), or in serious cases to the National Crime Agency.

    The data format itself has historically been a friction point. NFIB packages were until relatively recently delivered via secure email with PDF attachments rather than API-level data exchange with force case management systems. The Home Office has been pushing for tighter integration, but the reality across 43 forces in England and Wales is that interoperability is patchy. Some forces have invested in fraud case management tooling; others are essentially working off spreadsheets.

    This is also where cross-contamination risks emerge. The same suspect data that NFIB shares with regional forces may also flow to private sector fraud prevention bodies through schemes like CIFAS, the Credit Industry Fraud Avoidance System. Your fraud report data can end up influencing credit decisions and financial services access for third parties connected to suspect profiles, without any of the affected individuals necessarily knowing. That’s a downstream consequence worth thinking about, particularly in the context of how poorly secured data pipelines across government systems can amplify these kinds of unintended exposures.

    The cybercrime gap: what NFIB doesn’t handle well

    Action Fraud NFIB how it works UK cybercrime reporting becomes particularly strained when the crime is technical. Pure cybercrime, unauthorised computer access, malware deployment, DDoS attacks, sits uncomfortably in the Action Fraud taxonomy. The NFIB analysts are mostly trained in financial fraud patterns. A report describing a credential-stuffing attack on a company’s customer database requires a different analytical skill set than a romance fraud cluster.

    The NCSC handles the more serious end of cyber incidents separately, and there’s a real coordination gap between the two bodies. NFIB might receive a report about fraudulent transactions that originated from a compromised account, without ever surfacing the upstream compromise to the NCSC. These two pipelines rarely talk to each other in a structured way. The NCSC’s Early Warning Service is excellent at what it does, but it is not joined up with Action Fraud’s reporting infrastructure at a technical level. That gap is exactly the kind of seam that organised cybercrime groups exploit.

    SIM swap fraud is a decent example of this blind spot in action. The financial loss gets reported to Action Fraud; the underlying telco exploitation that enabled it rarely gets properly triaged as the technical root cause. I’ve covered this pattern in detail when looking at how SIM swap fraud defeats two-factor authentication at the network level. NFIB sees the fraud outcome, not the attack vector.

    What the system is actually built for

    My honest read of the NFIB architecture is that it is designed to produce strategic intelligence about organised fraud, not to provide justice to individual victims. That’s not a criticism without context: you cannot operationally investigate 900,000 fraud reports a year with existing resources. The system makes a triage choice, and that choice is to use victim reports as signal collection rather than case initiation.

    The result is that your Action Fraud submission is, in most cases, feeding a dataset. It helps build the intelligence picture that might eventually take down a fraud group operating out of Eastern Europe or a UK-based money mule network. It contributes to ONS crime statistics. It is useful in aggregate. But for you, as an individual victim who lost money and wants someone held accountable, the system is not really designed to deliver that. Knowing that upfront at least saves you from waiting by the phone.

The Latest