4 min read

Intelligent fraud management: How Claude helps the risk team define, build and validate changes

Liquidity Lab
Liquidity Lab built the AI layer that iwocaPay's fraud vendor does not provide, powered by Claude Opus. iwoca's risk team now builds, validates and manages its impersonation fraud ruleset in plain English.

iwoca is one of Europe's most successful fintechs, with a suite of business financing products built around SME lending. One of the largest risks a lender carries is impersonation fraud. Credit assessment rests on the borrower's creditworthiness, and if the borrower is not who they claim to be, that assessment counts for nothing.

Liquidity Lab was engaged to help iwocaPay, iwoca's point of sale financing product, manage impersonation risk without adding friction to the sales funnel.

A powerful platform, and what it costs to run

The framework we implemented rests on a fraud risk scoring engine which scores every transaction against more than 200 data points: the items being bought, the device making the purchase, the IP address behind it, the number of prior transactions, and many more. It is a vended product from one of the leading fraud vendors in the market, a company with a 20 year history, a roster of tier 1 clients, and functionality nobody else matches.

However, that depth comes with a significant, ongoing cost:

  • A risk team member typically needs a two week training course before they can start using the platform, and one to two years to become genuinely proficient.
  • The vendor’s UX is legacy. Rulesets run to hundreds of lines with complex branching, and the platform shows them as unintuitive tables with no view of that structure. Errors are common and hard to spot.
  • Rule management is thin on top of that. Versioning is cumbersome, there is no practical way to compare one ruleset against another, and no way to replay an alternative ruleset against historical transactions.
  • There is no AI anywhere in it: no conversational interface, no automated rule checking, and nothing on the vendor's public roadmap.

For iwoca that meant a long dependency on a few trained specialists, lasting key person risk, and real operational risk, since errors in a ruleset can let fraudulent transactions through. Fraud is adversarial, so it also costs agility: the longer a rule takes to change, the more a lender loses once a weakness is found.

What we built

Our engagement was not only to implement the platform. It was to leave iwoca self-sufficient in running it. So we used Claude Code to build the rule management layer the vendor does not provide, and put Claude at the centre of it.

Claude did not just help write this software. Claude Opus runs inside the tool, on Amazon Bedrock within iwoca's own AWS environment, and does the substantive work every time a risk manager uses it. The surrounding code does no reasoning of its own: it gathers the source material, assembles a grounded prompt, and passes it to Claude.

Claude does three main things:

  • Explains the in-force ruleset. A risk manager asks what the current rules do and gets an answer in plain English, including the branching structure and the weight each rule carries. Claude reads the live configuration and cites the documentation it relied on. Establishing this used to take hours in the portal, and was much of what the two week course taught.
  • Writes new rules from a plain-English brief. A risk manager describes the change they want. Claude turns it into the platform's own configuration and shows what it would do before anything happens.
  • Validates changes before they go live. Claude confirms that every attribute the change refers to exists, then tests it twice: in an offline simulation which costs nothing, so a rule can be run through as many scenarios as the team wants, and against the platform's own scoring service in the test environment, which returns a real scored response.

What makes the drafting safe enough for a lender to deploy is the configuration reference underneath it. The vendor platform publishes no machine-readable description of itself, so Claude Code built one from over 3,000 pages of vendor documentation and a live catalogue pull: roughly 200 configuration types, 2,000 parameters and 4,000 permitted values, relevant to the tool version iwoca runs. Claude checks every proposed rule against it. Without that, it could produce a change reading plausibly but which is misconfigured.

The tool carries 1,400 automated tests behind a gate that blocks release unless a high test coverage of 97% is met. Claude's own answers were graded before handover too: on 98% of test questions it was given the right page of vendor documentation, and on every question the documentation did not cover it said so rather than guessing.

What changed

  • Nobody has sat the vendor's course. What those two weeks would have transferred now sits in the configuration reference, and in Claude's ability to apply it on demand.
  • Key person risk is reduced. Through the vendor’s portal this would have depended on one trained individual, working where nobody else could readily check them. Several people can now operate it, none needing deep portal expertise.
  • Errors are caught before production. Every proposed rule is checked against the platform's own catalogue before it is applied, and the same checks run across the rules already in place, so errors predating the tool are found rather than inherited.
  • The time consuming steps are gone, and changes go live sooner. What used to take the time was portal navigation and hand-building the rule, not deciding what it should do. Claude does the analysis, the drafting and the checking. The risk team directs it and approves the result. No engineering, no vendor portal, and no Liquidity Lab.
"We were not going to wait for a vendor roadmap to bring AI to a system we depend on. Liquidity Lab used Claude Code to build that layer for us, and Claude runs inside it: it reads our fraud rules, writes new ones from a plain-English brief, and checks them before anyone approves them."
Rob Jones, Co-lead, iwocaPay

Why this matters beyond iwoca

Little of this is specific to this platform or this customer. A great many businesses run a critical process on vendor software with the same three characteristics:

  • The people accountable for the outcome cannot safely change the system themselves.
  • The vendor has little or no AI capability on its roadmap, and no commercial reason to add one quickly.
  • The engineering effort needed to close that gap has never been worth funding for a single customer.

AI changes the third, and the first two follow from it. The pattern is two steps: use Claude Code to build the engineering layer the vendor never built, then put Claude inside that layer to run the system day to day. Risk, compliance, pricing, underwriting, collections and servicing configuration all sit on software of this kind.

If you run a critical process on software you cannot safely change, we would be glad to talk about what this looks like in your business. Reach us at contact@liquidity-lab.com.