Study guide 2 · for the 17 October review · Luxembourg Digital Bank

TrustAge, part 2

Where the points come from, how it learns by itself, and how it starts in a brand-new bank.

This guide explains what is new since the 10 October proposal. Read the first study guide for the basics (the 8 rules, buying time, the mule ring). This one answers the three questions from the feedback: how exactly do we give points to a case, how does the detector adapt without anyone touching it, and what does the bank-level architecture look like.

≈ 20 min read3 calculators to try13 hard questions with answers10-question quiz

← Back to the start page · Open the 17 October deck

Part 1

What changed since 10 October, and why

The core idea is the same: a fraudster can steal a password, but not time. Every account takeover needs something new on the path to the money, so we measure how old each link is. What changed is how concrete and how self-running the design is.

Topic	10 October	17 October	Why
Architecture	Customer, LuxTrust, receiving bank, CSSF, IT and four staff roles on one picture	Only LDB's own systems, the detector's three parts, one learning loop and two people	Feedback: too wide, unnecessary players. The detector's job happens inside the bank.
Points	Expert bands: strong 30–50, medium 15–25, weak 5–10	One formula for every signal: points = 7 × log₂(fraud share ÷ genuine share)	Feedback: be concrete about how a case gets its score. Now every number has a reason and a meaning.
Adapting	Fraud lead retunes monthly, second person approves	Auto-tuner recounts every week, tests itself, writes a log; people can veto	Feedback: it must adapt without someone's intervention (not necessarily machine learning).
History	Assumed 24 months of old LDB transfers	No history: trust starts at the verified onboarding	LDB is a new bank, so there is no old data to load.
Reports	Described in words	Five mockups with example numbers	Required for 17 October.
Some points	R1 24–72 h +25, VoP no match +30, crowd IBAN +35	+35, +35, +40	The formula gave these values. All worked examples keep the same action.

Part 2

The architecture at bank level

Everything on this picture lives inside Luxembourg Digital Bank. Outside parties (the customer, LuxTrust, the receiving bank, the CSSF) still exist, but they are not part of the detector, so they are no longer drawn. Press Play to follow one payment, then the learning loop.

Ready

Each part: what goes in, what comes out

Part	Input	Output	Who uses it
Online banking + payment hub	The customer's transfer	Asks the detector before sending; sends only if allowed	The payment process (already exists at LDB)
1 · Transaction loader	The order + bank records (logins, devices, security changes, KYC, payees, mule list)	One checked record. Missing fields are flagged and add points; nothing passes silently	Automatic
Attribute builder	The checked record	Link ages (from the verified onboarding), 72-hour totals, how many customers pay this IBAN	Automatic
2 · Fraud engine	Attributes + the current points table	Score, action, reason codes, one plain sentence, in under 0.3 s	Automatic
Results store	Every decision	Append-only audit trail with the table version used	Audit, CSSF, the learning loop
3 · Report engine + console	Results + outcomes	Five reports (Part 8)	Fraud analyst, fraud lead, management
Auto-tuner	Outcomes + genuine rates of the last 90 days	The next points table, only if it passes the safety test	Automatic; the fraud lead reads the log

Operating model in one sentence: the detector decides most payments alone in under a second; a fraud analyst decides only the held ones (score 70+), after a call to the phone number verified at onboarding; the fraud lead never has to act, but reads the weekly log and can veto any change.

Instant payments and the 10-second rule

Instant transfers must reach the payee's bank within 10 seconds (Instant Payments Regulation 2024/886). TrustAge answers in under 0.3 s, so Allow, Warn and a passed LuxTrust check stay instant. If a 1-hour release, a hold or a block applies, LDB refuses the instant order within the 10 seconds and tells the customer at once, with the reason (PSD2 Art. 79). As LDB's terms allow, the payment then continues as a standard SEPA transfer, which must arrive by the end of the next business day (PSD2 Art. 83). So every hold has a hard deadline: decide by D+1.

When people are the bottleneck

Nights and weekends. One analyst is on call for P1 and P2 alerts (about 2 holds a day, so one person is enough). P3 waits for the next business day, as planned, which is still inside the D+1 deadline.
Customer not reached. Two calls to the onboarding phone plus an in-app message. If there is still no answer at the D+1 cut-off, the payment is refused and the customer is told. A held payment is never released by default.
Scam wave. If holds still exceed capacity with the hold line at its maximum of 75 (Rail 7), the fraud lead sends the in-app warning from the campaign board, the queue is sorted by amount at risk, and a trained colleague from operations joins the queue.
Safe channel for every message. For 30 days after a phone, email or LuxTrust change, warnings and confirmations also go to the old phone and email. Otherwise the "Warn" message after a SIM swap would go to the criminal's new number.

Part 3

How we give points to a case

For every signal we ask two simple questions:

F: out of 100 frauds, in how many does this signal appear?
G: out of 100 genuine payments, in how many does it appear?

F ÷ G tells us how much more likely fraud becomes when we see the signal. Bankers call this a likelihood ratio. The formula turns it into points:

points = 7 × log₂(F ÷ G), rounded to 5

Every +7 points means the odds of fraud double. +14 means 4×, +21 means 8×, +70 means about 1,000×.

Why a logarithm? Because it lets us add.

Evidence multiplies: a signal that makes fraud 9× likelier, plus one that makes it 40× likelier, together make it about 360× likelier. Multiplying is hard to explain to a risk officer. The logarithm turns multiplying into adding: +20 and +35 points simply add up to +55. That is why the score is a simple sum, and still means something precise. Credit scorecards use the same trick ("points to double the odds").

Worked example: R3 fresh payee

A payee added less than 24 h ago, payment ≥ €500
F = 70% of frauds · G = 8% of genuine payments
70 ÷ 8 = 8.75× more likely
7 × log₂(8.75) = 7 × 3.13 = 21.9 → +20 points

Good signs work the same way, in reverse

M1 trusted payee (paid twice, ≥ 30 days apart)
F = 5% · G = 60% → 0.08× → 7 × log₂(0.08) = −25.1 → −25 points

Where F and G come from

G (genuine share) is measured, not guessed. Over 99.9% of payments are genuine, so LDB counts G on its own traffic. After 30 days (≈ 75,000 transfers) every G is precise to a few tenths of a percent.
F (fraud share) starts as an estimate from public cases (fake BILnet site, SIM swaps, fake bank calls), our 40-scenario library and the fraud team's judgment. Then the detector corrects it with real cases (Part 6).
The estimate is robust. If our F is wrong by half (35% instead of 70%), the points move by only 7 × log₂(2) = 7. If it is wrong by a third, by 4. That is the advantage of the log scale.
No double counting. Extras such as "+ IBAN edited" or "+ amount far above normal" are measured among fresh-payee payments only, so they add only what is new. Signals that often come together are capped per rule (R2 max +50, R5 max +35, good signs max −40). R5 (drain) overlaps with R3, because a drain usually goes to a new payee; its cap keeps that in check. And the calibration check (Rail 9) tests whether the summed score still matches reality.

Try it: give a signal its points

F · in how many of 100 frauds does it appear? e.g. 70 for a fresh payee G · in how many of 100 genuine payments? e.g. 8 (measured on LDB's payments)

+20points

What a score means

We assume, for planning, that 1 in 20,000 LDB transfers is account-takeover fraud (LDB measures its real rate from month 1; for comparison, the EBA and ECB put EU credit-transfer fraud at about 0.001% of value in 2024). Then every score has a probability:

0–29 · Allowunder 1 in 1,000 such payments is fraud

30–49 · Warn1 in 1,000 to 1 in 160; the owner is notified (also on the old phone or email after a change)

50–69 · Check1 in 140 to 1 in 25; LuxTrust check, 1-hour release if new payee ≥ €1,000

70–89 · Hold1 in 20 to 1 in 4; the analyst calls before release

90+ · Block1 in 4 or more; session ends, access blocked, call

How the score is shown: on screens the score is shown between 0 and 100 (the SIM swap's 135 appears as 100, the rent's −10 as 0). The odds use the raw sum. An override (O1–O4) lifts the score to its minimum, and the alert then shows the override's reason instead of odds.

Try it: what does a score mean?

Score drag the slider Planning rate: 1 fraud in how many transfers? change it to see how the meaning shifts

70points

Part 4

The full points table

All 27 signals, 5 good signs and 4 overrides. F is our starting estimate, G is LDB's expected genuine rate (replaced by the measured rate after 30 days). P = alert priority: P1 answered within 15 minutes 24/7, P2 within 1 hour, P3 next business day.

ID	Signal (trigger)	F	G	×	Points	P	Business reason
R1 · Control change, then money out
R1a	Phone, email, password or LuxTrust changed < 24 h ago, then ≥ €500 to a fresh or young payee (72 h total)	35%	0.3%	117	+50	P1	SIM swap and account recovery attacks change the controls first. Honest customers rarely change their phone and pay a new person the same day.
R1b	Same, change 24–72 h ago	10%	0.4%	25	+35	P1	Patient criminals wait a day to avoid simple "same-day" rules.
R1c	Same, change 3–7 days ago	6%	1%	6	+20	P2	The points fade with the age of the change instead of stopping at 72 h, so waiting a few days does not reset the risk to zero.
R2 · Unfamiliar access (cap +50)
R2a	Device first seen < 24 h ago	55%	6%	9	+20	P2	Stolen credentials are used on the criminal's device. New phones are common, so it is only medium evidence.
R2b	Hosting provider, VPN or Tor network	15%	3%	5	+15	P2	Hides the criminal's location. Weak, because cross-border workers use VPNs.
R2c	Session break: network AND browser fingerprint change mid-session	20%	0.15%	133	+50	P1	Typical of a stolen session cookie or a fake-site relay.
R3 · Fresh payee with value at risk
R3a	Payee added < 24 h ago, payment ≥ €500	70%	8%	9	+20	P2	Money must reach the criminal's account, which is almost always new to the victim.
R3b	Young payee (1–30 days), ≥ €500	15%	6%	2.5	+10	P2	Some criminals add the payee days before using it.
R3c	+ IBAN of an existing payee was edited (measured among fresh payees)	11%	2.5%	4.4	+15	P2	Editing a trusted payee's IBAN hides the new account behind an old name.
R3d	+ amount > 2× the customer's own 95th percentile (among fresh payees)	50%	15%	3.3	+10	P2	Criminals take as much as possible at once.
R4 · Name or purpose contradiction
R4a	Name check (VoP) says "no match" and the customer continues	25%	1%	25	+35	P2	Mule accounts are in other people's names; coached victims are told to ignore the warning.
R4b	VoP "close match"	10%	3%	3.3	+10	P2	Small spelling differences are common for honest payees too.
R4c	VoP not possible (receiving bank does not answer)	5%	2.5%	2	+5	P3	Missing evidence is a small risk, never a free pass.
R4d	+ purpose answer contradicts the payee (e.g. "invoice" to a private person, "security transfer")	20%	4%	5	+15	P2	Scam scripts make victims choose odd purposes.
R5 · Drain and split (cap +35)
R5a	72 h total to fresh/young payees ≥ 50% of the balance	60%	5%	12	+25	P2	Fraud empties the account, even in small pieces.
R5b	Same, ≥ 80% of the balance	40%	1%	40	+35	P2	Very rare for honest customers unless declared (e.g. buying a flat).
R5c	72 h total ≥ 3× the customer's usual 72 h	45%	9%	5	+15	P2	Sudden change against the customer's own habit.
R6 · Risky destination
R6a	Payee IBAN on the mule list	override O1 → 90+				P1	Confirmed criminal account.
R6b	New IBAN paid by ≥ 3 unrelated LDB customers in 72 h (or 2 waiting in a 1-hour release)	10%	0.2%	50	+40	P1	One mule collects from many victims. Only a bank-wide view can see it.
R6c	Payee is an LDB account that passes money on within hours	5%	0.3%	17	+30	P1	LDB itself may host a mule. Also sent to AML.
R6d	First ever payment to a crypto or e-money provider	10%	3%	3.3	+10	P2	Hard to recall once converted.
R7 · Scripted or coached session
R7a	Login to confirm < 30 s with a pasted IBAN	20%	4%	5	+15	P2	Scripts and relays are faster than humans.
R7b	Remote-access tool active during the payment	10%	0.3%	33	+35	P1	"Tech support" scams take over the victim's screen.
R7c	Pause > 3 min on the confirm page	25%	8%	3.1	+10	P3	The victim waits for the caller's instructions.
R8 · Probe, wake or set-and-forget
R8a	Test payment ≤ €10, then ≥ 20× that within 48 h to the same payee	10%	2%	5	+15	P3	Criminals check the mule account works first.
R8b	Account dormant ≥ 90 days wakes up with a transfer	8%	2%	4	+15	P3	Owners of quiet accounts notice late.
R8c	New or edited standing order to a fresh payee	5%	1%	5	+15	P3	Slow theft that repeats every month.
R8d	≥ 3 declined or held attempts in 24 h	6%	0.5%	12	+25	P2	The criminal keeps trying smaller amounts.
Good signs (mitigators, max −40 together; never cancel an override)
M1	Trusted payee: paid twice, ≥ 30 days apart	5%	60%	0.08	−25	–	Criminals almost never use the victim's old payees.
M2	Well-known payee: on LDB's biller/notary list, or paid by ≥ 20 customers over ≥ 30 days	3%	25%	0.12	−20	–	Utilities, tax office, notaries are not mules.
M3	Old or anchored device on the usual home or mobile network	30%	70%	0.43	−10	–	Small, because coached victims use their own device.
M4	Payment declared in advance from a trusted channel (or payee declared at onboarding)	0.5%	10%	0.05	−30	–	Lets big honest payments through without friction.
M5	Within habit: amount ≤ usual, usual time and payee type	15%	50%	0.3	−10	–	Reduces false alarms for regular customers.
Overrides (fixed; never changed by the auto-tuner)
O1	Payee on the mule list	score at least 90				P1	Block.
O2	Session break (R2c) + fresh payee	at least 90				P1	Block: classic relay attack.
O3	≥ 2 control changes in 24 h + fresh payee + ≥ €1,000	at least 70				P1	Hold: full account takeover pattern.
O4	Customer says "the bank / LuxTrust / police asked me to move it"	at least 70				P1	Hold: no real bank ever asks this.

Part 5

Worked examples, with the arithmetic

The same five cases as in the deck. Each line shows which signal fired and its points.

Case	Signals and points	Score	Odds (1 in 20,000 base)	Action
SIM swap · fraud €12,000 instant, 80% of balance	R1a +50 (reset 2 h ago) · R2a +20 (new device) · R3a +20 · R3d +10 (8× usual) · R5b +35	135 shown as 100	≈ 97 in 100 (from the raw 135)	Block, call the onboarding phone
Phone changed, new payee · alert card €4,800 instant	R1b +35 (2 days ago) · R3a +20 · R3d +10 (6× usual) · R4b +10 (close match)	75	≈ 1 in 13	Hold, analyst calls
Coached victim · fraud €18,000, own laptop, name matches	R3a +20 · R3d +10 · R5b +35 · R7c +10 (4-min pause) · M3 −10	65	≈ 1 in 33	Check + 1-hour release (hardest case)
Buying a flat · honest €320,000 to a notary, declared	R3a +20 · R3d +10 · R5b +35 · M4 −30 · M2 −20 (capped at −40)	25	≈ 1 in 1,700	Allow
New customer's rent · honest €1,450, account 5 days old	R3a +20 · M4 −30 (landlord declared at onboarding). Device and phone are anchored, so R1 and R2 do not fire.	−10 shown as 0	≈ 1 in 54,000	Allow

Say this openly: the coached victim on her own laptop with a matching name is the hardest case for any detector. TrustAge does not block her; it buys an hour (the 1-hour release she can cancel), during which the scam call often ends and other customers paying the same IBAN are spotted.

Part 6

How it adapts by itself, without anyone touching it

This is counting, not machine learning. Every week the detector recounts the two numbers of the formula (F and G) for every signal, from what really happened, and recomputes the points. A person can read and redo every step in a spreadsheet.

1 · every payment

Decide

Score with the current points table. Store the reasons and the table version.

2 · as it happens

Learn the outcome

Each payment later gets a label (see the table below).

3 · every Sunday 03:00

Recount

New F and G for every signal, new points with the same formula.

4 · before going live

Safety test

Replay 40 scenarios and the last 30 days. Fail? Change rejected, fraud lead alerted.

Where the outcomes (labels) come from

Source	When	Counts as	Why it matters
Analyst decision on a held payment	Minutes	Fraud or genuine	Fast and reliable, but only covers what was held.
Customer cancels during the 1-hour release	Within the hour	Half a fraud case	Often a scam that the customer realised; not always.
Customer's fraud claim later (PSD2 allows up to 13 months)	Days to months	Fraud (a missed case)	The most valuable label: it teaches the detector what it did not see, so it does not only learn from its own alerts.
Receiving bank confirms a mule / recall result	Days	Fraud	Also adds the IBAN to the mule list at once.
Blocked payment, after the call	Hours	Fraud if the customer did not make it; genuine if they did; no label if not reached	A block alone never counts as fraud, so the detector cannot prove itself right.
No complaint 60 days after the payment	60 days	Genuine (can still flip)	Feeds G, the genuine share. In the first 60 days after launch, G is counted on all payments minus known frauds and claims (fraud is so rare that the error is below 0.01%).

The recount formula

F_new = (20 × F_estimate + fraud cases with the signal) ÷ (20 + all fraud cases)

Our first estimate counts like 20 cases. With few real cases, the estimate dominates; with many, reality takes over. G is simply measured on the last 90 days of genuine payments (in the first 60 days after launch: all payments minus known frauds).

Example, month 4 · R3 fresh payee · 25 confirmed frauds since launch, 21 had a fresh payee
F = (20 × 70% + 21) ÷ (20 + 25) = 35 ÷ 45 = 78%
G = measured on LDB = 5.5% (our guess was 8%)
78 ÷ 5.5 = 14× → 7 × log₂(14) = 26.7 → +25 (was +20; within the +5 limit)
Log: "R3 fresh payee +20 → +25: 21 of 25 confirmed frauds had one; only 5.5% of genuine payments do."

Try it: watch a rule learn

Our first estimate F (%) e.g. 70 for R3 Confirmed fraud cases since launch all of them …of which had this signal Measured genuine share G (%) Current points

+25new points

The safety rails (why self-tuning is still auditable)

Rail 1

Expert estimate = 20 cases

One or two odd cases cannot swing a rule.

Rail 2

Max ±5 points per week

Change is gradual and visible. Each rule also has a floor and a ceiling (for example R1a never below +30).

Rail 3

Overrides are frozen

Block rules (O1–O4) and the −40 cap on good signs never change by themselves. Only people can change them, with four eyes.

Rail 4

Safety test before going live

All 40 library scenarios must still reach their action, and holds on the last 30 days must stay under analyst capacity (30 per day). Otherwise the change is rejected.

Rail 5

Drift alarm

If a signal suddenly fires on many genuine payments (G doubles in a week, e.g. after a browser update), its points are halved for 7 days and the fraud lead is told. Sudden jumps are never trusted.

Rail 6

New signals start silent

Extra data (supplementary attributes) is scored at 0 and only measured. Once seen in ≥ 5 frauds with F ÷ G ≥ 4, it is promoted automatically, at most +15. Bigger needs a person. This is how new fraud tactics get covered without redesigning anything.

Rail 7

Hold line follows capacity

The hold line may move between 65 and 75 by itself to keep holds within what the analysts can handle.

Rail 8

Everything is logged and reversible

Every table version is stored with one sentence per change. The fraud lead can veto or roll back in one click. Risk (second line) reviews the monthly learning report.

Rail 9

Calibration check

Adding points assumes the signals are independent, and some are not. So the KPI page checks the score against reality in two steps. From day 1, the genuine side: the G values predict how many genuine payments should land in each band (for example about 0.1% in Hold); if the real share is more than 2× off, the fraud lead is told. From about 30 confirmed frauds (around month 5), the fraud side too: the odds each band promises (a hold: 1 in 20 to 1 in 4) against the real fraud share in that band. Overlapping signals show up here.

Real-time parts that also adapt by themselves: the mule list (a confirmed fraud IBAN is added within minutes), payee reputation (IBANs paid safely by many customers become "well known"), and each customer's own baseline (usual amounts, recomputed nightly). And the core idea adapts by design: devices and payees age into trust on their own.

Part 7

Starting in a brand-new bank, with no history

LDB has no old transactions to learn from. TrustAge does not need them, because it does not ask "is this unusual for this customer?" (which needs history). It asks "was this link verified at onboarding, or added later?"

Idea 1

Trust starts at onboarding

Opening an account at LDB means eKYC plus LuxTrust registration. The device, phone and email verified at that moment are anchored: trusted from day 1. A takeover always changes something after that, and that change is what R1 and R2 catch.

Idea 2

Early-trusted payees

Three routes: (a) the customer's own account at their old bank that funded LDB (same name, verified by VoP), (b) payees declared at onboarding (landlord, employer), (c) a preloaded list of Luxembourg billers and notaries.

Idea 3

Genuine side in 30 days

Over 99.9% of payments are genuine, so G can be measured almost at once: 30 days of traffic (≈ 75,000 transfers) is enough for every signal.

Idea 4

Fraud side is borrowed

F starts from public cases, our scenario library and shared mule lists (fraud-data sharing will become mandatory under the EU Payment Services Regulation). Honest point: a small bank sees few frauds, so F learns slowly. In year 1 most learning comes from G and from capacity.

Idea 5

Stricter first 60 days

Criminals test new banks early. A launch pack keeps a 12-hour cooling-off after any new device, phone or email: that channel cannot approve fresh-payee payments ≥ €1,000.

Idea 6

Each new customer's habits

Until a customer has history, their "usual amount" comes from what they declared at onboarding, blended into real behaviour: weight w = min(1, payments ÷ 20, days ÷ 90).

Launch timeline

Before launch

Starting points from F estimates and benchmark G. Tested on 50,000 synthetic customers and 40 scenarios. Biller list and mule feed loaded.

Days 1–30

Launch mode: anchors give trust, hold line set by capacity, G measured every day. Weekly recount already running, ±5 limit.

Day 30

One larger, logged recount of G from LDB's own traffic. Must pass the safety test.

Month 3 onwards

Normal weekly self-tuning. F learning speeds up as cases build up, plus shared data from other banks.

Part 8

The five reports

The Report engine produces one report per person and purpose. See them as mockups on slide 6 of the 17 October deck.

Report	Who	When	What it shows	Decision it supports
1 · Alert card	Fraud analyst	Each held payment	One-sentence reason, points per signal as bars, link ages, the safe phone number, customer snapshot, what the customer was told	Release or stop, within 15 min (P1) or 1 h (P2)
2 · Queue	Fraud analyst	Live	Held payments by priority and time left, with status	What to work on next
3 · Campaign board	Fraud lead	Daily	New IBANs paid by several customers, signals above normal, possible scam waves	Warn all customers? Add an IBAN to the mule list?
4 · What TrustAge learned	Fraud lead, risk (2nd line)	Monthly (weekly log)	Each automatic change with its reason, drift alarms, promoted signals, safety-test result, vetoes	Veto or accept; audit evidence
5 · KPI page	Management	Monthly	Fraud stopped, losses vs risk appetite (1 bp of transfer value), precision, holds vs capacity, calibration per band, customer friction, speed. Each fraud is tagged with its EBA category for LDB's semi-annual fraud report to the CSSF (PSD2 Art. 96(6))	Is the risk within appetite? Staffing?

Part 9

Hard questions the committee may ask

"Your fraud percentages are still guesses, aren't they?"

At the start, yes, and we label them as estimates. But they are only half the formula; the other half (G) is measured on LDB's own payments within 30 days. The log scale makes guesses robust: if F is wrong by half, the points move by 7. And the recount replaces the guess with real cases automatically.

"Don't you count the same evidence twice?"

Add-on signals (IBAN edited, amount far above normal) are measured only among payments that already have a fresh payee, so they add only new information. Signals that tend to come together are capped per rule (R2 max +50, R5 max +35), and good signs are capped at −40. The safety test checks the total hold rate, and the monthly calibration check (Rail 9) compares each band with reality: on genuine payments from day 1, on fraud cases once about 30 are confirmed.

"A system that changes itself without people: isn't that a model risk?"

It changes itself only within rails: ±5 points per week, floors and ceilings, frozen overrides, a safety test before every change, a one-sentence log, one-click rollback, and a monthly review by the fraud lead and risk (second line). It never releases a held payment; people decide those. That is less risky than a monthly manual retune, which is slower and less documented.

"Could criminals poison the learning?"

Hard. After the launch period, G only uses payments that are 60 days old with no complaint. A sudden jump in any signal triggers the drift alarm and halves the points, instead of trusting the jump. The block rules cannot change by themselves. And a rule can move at most 5 points a week, so a slow attack would be visible in the weekly log for months.

"Doesn't it only learn from what it already catches?"

No: customer fraud claims (missed frauds) are labels too, and they are the most valuable ones. Under PSD2 a customer can report an unauthorised payment for up to 13 months, so the genuine label after 60 days can still flip to fraud.

"Why not machine learning?"

A new bank has no labelled fraud cases; a model would need hundreds. Our counting method is the honest version of learning: it uses exactly the evidence that exists, and every number is explainable. Once LDB has around 200–300 confirmed cases and a year of data, a model can be tested in shadow mode next to the rules.

"What does the AI Act say?"

Systems based on rules defined by people are generally outside the AI Act's definition of an AI system; our weekly recount is simple statistics on top of human-defined rules. Even if it counted as AI, systems used to detect financial fraud are explicitly excluded from the high-risk credit-scoring category (Annex III, point 5(b)). We keep human review of every hold anyway (GDPR Art. 22).

"Why trust a device on day 1 of a new customer?"

Because it was verified at onboarding with eKYC and LuxTrust, which is stronger evidence than time. To beat this, a criminal would have to take over the onboarding itself, which is the job of the KYC controls.

"Why 1 in 20,000?"

It is a planning assumption that only translates scores into odds; the points themselves do not depend on it. LDB measures its real rate from month 1. For context, the EBA and ECB report EU credit-transfer fraud at about 0.001% of value in 2024.

"Why weekly and not in real time?"

Fraud outcomes arrive with a delay (days to months), so recounting every minute would only add noise. Weekly gives enough cases, a stable version history and a safety test each time. The parts that must be fast are fast: the mule list updates within minutes, baselines nightly.

"Which rule actually requires a detector like this?"

The PSD2 rules on strong customer authentication (Delegated Regulation 2018/389, Art. 2) require transaction monitoring that considers at least: compromised or stolen credentials (R1 control change, R2c stolen session), the amount (R3d, R5), known fraud scenarios (our 40-scenario library, mule list, R6, R8), signs of malware in the session (R7b remote-access tool) and abnormal use of the device (R2a new device, LuxTrust anchors). PSD2 Art. 96(6) adds fraud reporting to the CSSF, which the KPI page feeds. The system itself falls under DORA, and the privacy side (DPIA, GDPR) is in the first study guide.

"A coached victim authorises the payment herself. Why is that LDB's problem?"

Under PSD2, the bank refunds unauthorised payments, so a coached victim today usually carries the loss. The new EU Payment Services Regulation (provisionally agreed by Parliament and Council in November 2025, not yet in force) changes this for one case: when the criminal pretends to be the bank's staff and the customer reports it to the police, the bank must refund in full. That is why O4 ("the bank asked me to move it") forces a hold, and why the 1-hour release and the purpose question (R4d) matter even though TrustAge is built for account takeover.

"Criminals will learn your thresholds. Then what?"

The design makes thresholds hard to game. R1 fades over 7 days instead of stopping at 72 h (R1a, R1b, R1c). R5 looks at 72-hour totals, so splitting under €500 does not help, and R8d catches repeated tries. The thresholds are not published, and the weekly recount moves points as tactics change. What criminals cannot fake is time: a payee or device they add is new, whatever amount they choose.

Part 10

Main assumptions and limits

F estimates are starting values from public cases and expert judgment. They are clearly labelled and replaced by real counts over time.
Planning rate of 1 fraud in 20,000 transfers; volumes of about 2,500 transfers a day in the first months.
The hub can call the detector before executing a payment (answer within 0.3 s). If the detector is down or gives no answer within 0.5 s, a fixed fallback applies: payments to trusted payees go through; fresh-payee payments ≥ €1,000 are not sent as instant and wait as standard transfers until the detector is back (if it is still down at the D+1 cut-off, an analyst decides them by hand); IT is alerted (DORA incident process).
LDB's terms allow a payment to be held for a safety check (PSD2 Art. 79 requires this before refusing).
Small-bank learning is slow on the fraud side: about 25 confirmed cases in the first 4 months.
Blind spots: coached victim with matching name; mules that collect from only one LDB victim; attacks through channels the detector does not see (for example cards).
Web app limits: LDB's online banking runs in a browser, where remote-access tools (R7b) and session fingerprints (R2c) are harder to see than in a mobile app. Their F values are kept modest for that reason.
Mule accounts at LDB: a new digital bank attracts people who open accounts to receive stolen money. R6c sees money passing through; stopping such accounts at opening is a KYC and AML task, not TrustAge's.

Part 11

Test yourself

Pick an answer. You see at once if it is right and why.