Configuration, Not Intelligence: Where AI Belongs in Threshold Logic

On 30 June 2026 the customer due diligence trigger for an occasional wire transfer became eight hundred pounds. The threshold governing what information must accompany that same transfer remained one thousand euros, because it sits in the assimilated wire transfer regulation, which was not amended. Compliance teams have written the note. Payments teams now have to build it. Yet the difficulty is not that there are two numbers. They behave differently in three respects, and only one comes with instructions.

The instinct in 2026 is to reach for a model. Threshold logic looks like exactly the kind of fiddly, rule-laden, exception-strewn work that machine judgement was supposed to absorb. But it is close to the opposite. The question has a right answer, a published rate and a date. Those are the three things a model is worst at holding still.

The conversion rule now points outwards

Start with the mechanic nobody has noticed. Regulation 3(2) of the money laundering regulations used to convert inwards. The equivalent in sterling of a sum expressed in euros was determined by converting that sum using the London closing exchange rate for the euro and the relevant currency for the previous working day. Firms built to that rule for nine years, and vendors built to it for them.

The June instrument reversed it. Every operative word was substituted, so the provision now takes a sum expressed in sterling and converts it into another currency, using the London closing rate for sterling for the previous working day. A firm processing a euro-denominated payment must convert eight hundred pounds into euros to know whether the customer must be identified. The rate is the previous working day's, which on a Monday means Friday's.

That is a prescribed method, and prescribed methods are a gift. The assimilated wire transfer regulation has nothing equivalent. It states one thousand euros and stops. There has never been a statutory rule for converting it, and the money laundering regulations cannot supply one, because regulation 3 interprets those regulations and not another instrument. One threshold arrives with a rate source, a currency direction and a timing convention. The other arrives bare.

Firms have always had to invent a method for the euro figure. The invention was invisible while both instruments spoke the same currency. It is visible now, and it is the firm's own.

Aggregation behaves differently

The second divergence is not about the figures at all. Articles 5(2), 6(2) and 7(3) of the wire transfer regulation each apply whether a transfer is carried out in a single transaction or in several which appear to be linked. Aggregation is built into the euro line at every point it operates.

Regulation 27(1)(b) carries no such wording. Its neighbours do; regulation 27(2) applies whether a transaction is executed in one operation or several appearing to be linked, and regulation 27(7E) aggregates cryptoasset transfers expressly. The occasional transaction trigger for a wire transfer does not. Read plainly, the sterling test looks at the payment in front of it. The euro test looks at a window.

The drafting may be deliberate or it may be an artefact of amending one instrument and not the other; either way a firm has to operate it. A payments platform needs two aggregation behaviours running over one transaction stream. Most were configured for one, because until June there was only one.

The order of the tests inverts

The third divergence only appears when the market moves. Eight hundred pounds equals one thousand euros at precisely one and a quarter euros to the pound. Below that rate the sterling threshold is reached first, so a customer is identified before the message must be enriched, which is a coherent sequence and the one most firms will have assumed. Above it, the order reverses.

This is the failure that will not announce itself. Logic that evaluates the enrichment test only after the identification test has passed produces correct answers at one rate and quietly wrong ones at another. It raises no exception, generates no alert and leaves no artefact. It stops asking a question it used to ask, and says nothing.

This is not a problem AI solves

Three divergences, two currencies and a rate that moves. Everything about this looks like a problem that wants intelligence. Yet the threshold question is deterministic. Two figures, one published rate, one transaction value, one date. It has a correct answer. A supervisor asking which figure was applied to a given payment expects a reproducible one, with the rate used and the day it came from.

A rules engine produces that. A model produces something that resembles it, and resemblance is not evidence. Introducing probabilistic reasoning into a question with a determinate answer imports a failure mode and buys nothing in return. One test applies to any proposed use. If the same inputs must always give the same output, and a supervisor can ask why, the work belongs in configuration.

There is a sharper reason to keep models away from this particular question. Most policy documents, vendor guides, training decks and industry notes in circulation still say one thousand euros, because until 30 June that was right and little has been rewritten since; UK Finance's own interpretative guidance still cites the superseded European provisions. A system trained on that corpus is likely to answer confidently and wrongly, and to answer wrongly in the direction of the old law. Fluency is not currency. The tools most likely to be asked are the ones least likely to know.

Where the machine earns its place

But there is a role, and it is a serious one. It simply sits one step earlier than anyone is looking.

Nobody noticed this split because nobody compared a statutory instrument against an instrument it did not amend. That is a document problem at volume. Read the instrument, map every provision it touched, then search the estate of policies, procedures, system configurations and training material for every monetary threshold and the provision each one derives from. Nobody does that by hand.

That work is high volume, low judgement and genuinely tedious, which is why it does not get done. It is also exactly what machine reading is good at. The output is not a decision; it is a list of places where a number appears without a citation, or with the wrong one. A human then adjudicates each. Detection of change, not exercise of discretion.

One genuine grey area remains, and it is worth naming because it has regulatory cover. Identifying linked transactions in real time is the hardest part of the euro line, and UK Finance records candidly that market convergence on it is not a realistic goal. The revised Recommendation 16 (R16) permits ongoing monitoring of accounts, transactions and activity as a whole as a route to alignment checks, which is pattern recognition by design. Aggregation is a reasonable place for a model. The threshold it feeds is not, and the distinction is worth holding.

What a defensible build looks like

Four things follow. Evaluate both tests independently on every in-scope payment, rather than nesting one inside the other, so that neither depends on the sequence in which they happen to fire. Store the outcome of each with the rate used, its source and its date, because the audit question will be which figure was applied and on what basis. Configure the aggregation window separately for each test rather than inheriting one from the other. Make the window a parameter, not an assumption buried in code.

And write down the conversion methodology for the euro line, since no instrument supplies it. The obvious approach is to mirror the statutory method that now exists for sterling, taking the London closing rate for the previous working day. A firm applying the rule Parliament wrote for one threshold to a threshold Parliament left alone is in a defensible position. That is a judgement, not a requirement. It belongs in a policy, not in a model.

The answer is a decision table

Two thresholds, two aggregation rules and an inverting sequence sound like complexity. They are not. They are a small decision table with four inputs and a date stamp. Firms will get this wrong not because it is difficult, but because nobody told them the table changed.

That is the shape of most threshold failures. Not an absence of intelligence but an absence of maintenance; not a system that could not work out the answer but a system that was never told the question had moved. The revised R16 arrives by the end of 2030 and will move several of these lines again. Firms that have built a configurable table and a change detection habit will absorb it in a release. Firms that have hard-coded a thousand somewhere will find it the way this one was found. By accident.

Could your systems tell a supervisor which threshold they applied to a payment last week, and the rate they used to get there?

If that answer requires an investigation rather than a report, we can help you build the table before someone asks; contact us.

At OpusDatum, we test threshold logic against the provision that actually governs each control, rather than against the figure carried across a policy library. Our wire transfer regulation work examines where due diligence triggers, payment data triggers and aggregation windows diverge, and whether a firm could evidence each of them separately on a named date.