TrustSphere Vendor Assessment: Arkose Labs, Excellent Against Machines and Largely Beside the Point Against a Persuaded Human

A large share of what arrives at a bank's login page, registration form and password reset flow is not a person. It is a script, running at volume, testing credential pairs bought in bulk, enumerating account identifiers, or registering accounts to harvest an incentive or to stage mule capacity. The economics are brutally simple: the attacker's cost per attempt is close to zero, and the defender's is not. Everything in this category is an attempt to invert that ratio.

Arkose Labs exists to attack the attacker's unit economics rather than to identify individuals. Its proposition is to detect automation at the session level and then impose a graduated cost on suspicious traffic, in the form of an interactive challenge that is cheap for a genuine human and expensive to defeat at scale, whether by script, by solver service or by a farm of clickers. Its commercial framing has often been explicit about warranting outcomes against credential stuffing and fake account creation, which is a more confident position than most vendors in this index take.

The buying problem is that this is a genuinely differentiated capability sitting in a narrow part of the estate, and buyers routinely mistake it for something broader. Bot mitigation is not fraud decisioning. It answers whether the session is automated; it does not answer whether a genuine, authenticated, entirely human customer is being talked into a payment by somebody on the telephone, which is the dominant loss driver in United Kingdom retail banking and the subject of today's companion theme post.

Score and Capability Profile

Arkose Labs scores 6.77 out of 10 in the TrustSphere RiskTech Index, against an index mean of 6.06, in the category of bot and automated abuse deterrence. That is clearly above mean and it is earned, but the shape of the profile matters more than the headline.

Taking the capability lines in order. Bot detection and automated abuse deterrence scores 9. Fake account creation and bulk registration prevention scores 9. Account takeover prevention, covering credential stuffing, credential spraying and scripted login attack, scores 8. Challenge design, attestation and user experience scores 7, as do device intelligence and delivery, latency and integration. Attack analytics, reporting and evidential record scores 6. Broader fraud detection scores 5. Behavioural biometrics scores 4, reflecting session level signal rather than a continuous behavioural proposition. Enterprise fraud risk management scores 3. Case management and investigation workflow scores 2, transaction monitoring and screening scores 2, watchlist and sanctions screening scores 2, eKYC and KYB scores 2, and identity verification and liveness scores 2.

The weighting vector is published so the arithmetic can be checked. Bot detection and automated abuse deterrence carries 20 percent, account takeover prevention 15 percent, fake account creation and bulk registration 12 percent, challenge design, attestation and user experience 8 percent, broader fraud detection 8 percent, device intelligence 7 percent, delivery, latency and integration 6 percent, behavioural biometrics 5 percent, attack analytics, reporting and evidential record 5 percent, enterprise fraud risk management 4 percent, case management and investigation workflow 3 percent, transaction monitoring and screening 3 percent, watchlist and sanctions screening 2 percent, eKYC and KYB 1 percent and identity verification and liveness 1 percent. Those fifteen weights sum to 1.00 and, applied to the scores above, produce a composite of exactly 6.77.

The unweighted mean of the same fifteen scores is 5.0. The distance between 5.0 and 6.77 is the entire assessment in one number. The weighting places nearly half its emphasis on the three lines where this vendor is outstanding, and the product still lands well short of the 8 or 9 a casual reader might infer from those marks. Read 6.77 as a statement that Arkose Labs is one of the strongest assets in the index inside a perimeter covering perhaps a fifth of a financial crime estate, and close to absent outside it.

What It Actually Does Well

The differentiated strength is the cost imposition model, which is a genuinely different idea from detection scoring. Most defences try to classify traffic and block what they believe is bad, which means every false positive is a rejected customer and every false negative is a free attempt. A graduated challenge changes the shape of the problem: the marginal attempt becomes expensive for the attacker while remaining cheap for the customer. Against credential stuffing, where the attacker works a list with a low hit rate, that is exactly the right lever.

The second strength is resistance to defeat, which is where the engineering investment sits. The hard problem here is not distinguishing a naive script from a browser; it is staying ahead of commercial solver services, machine vision models trained against the challenge set, and outsourced human solving farms. Arkose Labs has treated challenge variety, dynamic difficulty and continuous adversarial iteration as the core product rather than a feature, and the attestation approach, where the challenge result is cryptographically bound to the session it was issued for, closes the replay and token resale route that undermines simpler implementations.

The third strength is operational fit at the edge. The product deploys in front of login, registration, password reset and similar high volume endpoints, behaves as a service call with predictable latency, and produces an attack telemetry picture that many security and fraud teams find more useful than their own logs: campaign level views of attack volume, origin, tooling and success rate over time.

Where the Limitations Are

The first limitation is the one buyers most often fail to internalise. Bot mitigation is not fraud decisioning, and the product's scope ends at whether the session is automated. It has no view of the payment, no beneficiary intelligence, no rules engine for transaction risk, no scam typology model and no ability to intervene at the moment money leaves. In the recovery room scenario described in today's theme post, the attacker is a human on a telephone and the customer is genuine, authenticated, unhurried and making the payment themselves. Every control in this product will pass that session correctly, because nothing about it is automated. A firm buying Arkose Labs to reduce authorised push payment losses has misunderstood what it bought.

The second limitation is friction and accessibility, and it deserves more scrutiny than it usually receives. A challenge is by definition an imposition on the user, and the population it lands on is not evenly distributed. Customers using assistive technology, customers with motor or visual impairment, customers on old devices or poor connections, and customers routed through corporate proxies or privacy networks are all more likely to be challenged and more likely to fail. Accessibility work in this product is real, but the residual risk sits with the bank. Under the Consumer Duty and equality obligations, a control that disproportionately excludes disabled or older customers from a login flow is a firm level problem, and it must be measured on your own completion data by segment rather than assumed away by a compliance statement.

The third limitation is evidential. The output is a determination about a session, not a record about a person or a transaction, and it is retained on a short operational horizon. That is entirely appropriate for its purpose and entirely unsuitable as an audit artefact. There is no case management, no investigator workstation, no alert lifecycle, no suspicious activity reporting path and no ability to reconstruct, two years later, why a particular session was challenged or allowed. Firms using challenge outcomes as an input to a fraud decision must decide in advance what they will store, in what system, and how they will explain it to a supervisor or an ombudsman. Relatedly, the vendor's outcome guarantees are contractual instruments defined against specific attack types and measurement methodology, and the exclusions deserve a careful legal read rather than acceptance at the level of the headline.

The fourth limitation is integration and organisational ownership. Deployment is at the edge, touching the web and mobile estate, the edge security layer, the identity and access management stack and, in practice, three or four teams. Native mobile applications require client integration work rather than a script tag. More awkwardly, the product typically sits in the security or platform budget while the losses it prevents are recorded in fraud, so cost and benefit land in different places on the organisation chart. We have seen more value destroyed by that misalignment, through ownership gaps and unmaintained tuning, than by any technical shortcoming in the product. There is also no transaction monitoring, no sanctions or watchlist screening and no anti money laundering capability of any kind, and nobody should be surprised: it is not what the company builds.

Questions to Press in the Demo

Do not spend the session watching challenge demonstrations, which are impressive and prove nothing about your traffic. Spend it on what happens to your genuine customers, what you will hold as evidence, how the guarantee is actually defined, and who inside your organisation will own this once it is live.

• Run a passive observation period across our real login and registration traffic and show us the proportion you would have challenged, broken down by device type, operating system age, connection quality and assistive technology use, before we agree any challenge policy.

• Show us challenge completion and abandonment rates for genuine customers in our most vulnerable segments, including customers over seventy and customers using screen readers, and tell us what completion rate you consider acceptable and why.

• Set out precisely what the outcome guarantee covers: which attack types, measured how, over what baseline, with what exclusions, what evidence we must supply to claim, and what the two most recent claims made against it by comparable clients looked like.

• Explain what data you retain about a challenged session, for how long, and demonstrate how we would reconstruct and evidence a specific session decision from eighteen months earlier for a regulator or a complaint.

• Describe, with named client examples, how attacker behaviour changed after deployment: what proportion of attack volume migrated to manual social engineering, call centre channels or new account routes rather than stopping, and how that migration was detected.

Verdict

Buy Arkose Labs if you have a measurable automated abuse problem: sustained credential stuffing against your login endpoints, bulk registration abuse at onboarding or in a rewards programme, or scripted enumeration of account or card data. In those conditions it is one of the better assets in this index and 6.77 understates its usefulness, because the composite is dragged down by lines the product never claimed. Buy it with a named owner sitting across security and fraud, a challenge policy tested against your own accessibility data, and a monitoring plan for where the attackers go next.

Do not buy it as a fraud platform, do not let it appear in a financial crime target operating model as though it were a control over payments, and do not buy it if your dominant loss is a human persuading a genuine customer to authorise a transfer, because it will not touch that. It pairs with a transaction fraud engine owning payment decisions, a case management platform owning the alert lifecycle and the evidential record, a behavioural biometrics or device intelligence provider for continuous in session assessment, and a scam intervention capability for the authorised push payment problem. It replaces none of them. Its honest place on the architecture diagram is at the edge, keeping the machines out, so that the rest of the estate is only dealing with people.

Suggested Next Steps

• Quantify your automated abuse problem before you go to market, separating credential stuffing, bulk registration, enumeration and scraping into distinct volumes with distinct losses, so that the business case rests on your own attack telemetry rather than a vendor benchmark.

• Insist on a passive observation phase against live traffic and analyse the would be challenge population by device age, connection quality, accessibility signal and customer age band before agreeing any policy that puts friction in front of customers.

• Decide in advance which team owns challenge policy, tuning and the relationship, and resolve the budget split between security and fraud in writing, because unowned edge controls decay quickly and silently.

• Plan explicitly for displacement: agree what you will monitor in call centre, branch, new account and authorised payment channels after deployment, and set a review point to test whether the attack moved rather than stopped.

Sources: Financial Conduct Authority financial crime guide, Consumer Duty and guidance on the fair treatment of vulnerable customers; Payment Systems Regulator mandatory reimbursement requirement for authorised push payment scams; National Cyber Security Centre guidance on credential stuffing, password security and denial of service; Open Worldwide Application Security Project automated threat handbook for web applications; European Banking Authority guidelines on outsourcing arrangements and on information and communication technology risk; DORA; PSD2 and strong customer authentication requirements; Equality Act 2010 and Web Content Accessibility Guidelines as applied to customer facing journeys; UK Finance fraud analysis; Arkose Labs published product and threat research materials; TrustSphere Risk Index, April 2026.

TrustSphere helps financial institutions design and deploy intelligent fraud and financial crime detection solutions. Visit www.trustsphere.ai