Rules And FLM
Loci rules are represented with FLM, the Fraud Language Model. FLM is an explainable control format for fraud and AML logic. It captures what a rule is trying to detect, which signals it uses, how it scores evidence, and when it should trigger.
FLM gives teams the clarity of rules with a more flexible, model-like evaluation pattern through MADIE.
Why FLM Exists
Traditional rule engines are often brittle and opaque once they grow. Black-box models can be powerful but difficult to govern. FLM sits between those extremes:
- Analysts can understand the control intent.
- Engineers can inspect the fields, thresholds, aggregations, and outputs.
- Reviewers can approve or reject changes before deployment.
- MADIE can evaluate the control consistently in real time.
Authoring Rules
Rules can be created in several ways depending on the deployment:
- Manual authoring in the rule editor.
- AI-assisted authoring from a fraud scenario, policy, or analyst prompt.
- Discovery-assisted authoring from observed patterns and historical behavior.
- Imported or generated FLM reviewed by an operator before deployment.
Human review remains important. AI can accelerate discovery and drafting, but production deployment should be governed.
Active And Inactive Rules
A rule's status determines whether it participates in live decisions.
- Active rules are evaluated in the live decision path.
- Inactive or paused rules can be edited and tested without changing customer-impacting decisions.
Inactive testing is the preferred workflow for tuning a rule before activation.
Shadow Evaluation And Historical Replay
Loci supports testing selected inactive rules against:
- A manually entered transaction payload.
- Stored historical transactions over a selected date range, where available.
- One rule or multiple rules at the same time.
This gives teams a safe pre-deployment testing workflow: test before launch, compare outcomes, inspect matched evidence, and deploy only when the control is ready.
The payload is sent through the live engine in shadow or evaluation mode, allowing teams to safely test rules with real data before activating the rule.
MADIE Evaluation
MADIE evaluates FLM controls in real time. It behaves more like a control-intelligence engine than a simple if-then rules list because rules can combine signals, aggregations, historical windows, thresholds, exclusions, and score-like behavior.
This lets teams evaluate explainable controls consistently while preserving the evidence needed for review and audit.
Stateful Aggregations
FLM rules are not limited to inspecting the transaction in front of them. They compute what the industry calls stateful aggregations: statistics over an entity's behavioral baseline, evaluated live at decision time rather than read from precomputed snapshots. This is the capability that catches organized and distributed fraud, where no single transaction looks wrong but the pattern across many does.
Supported aggregations:
| Statistic | What it answers |
|---|---|
| Counts | How many matching transactions in the window |
| Distinct counts | How many different values of a field, such as distinct beneficiaries, devices, or channels |
| Sums | Total amount moved in the window |
| Averages | The entity's normal behavior, as a live baseline |
| Minimum and maximum | The extremes of the window |
| Standard deviation and variance | How volatile the entity's behavior is |
| Most common value | The entity's usual merchant, channel, or location |
| Percentiles | Where a value sits in the entity's own distribution |
Aggregations combine arithmetically, so ratio-style controls are ordinary expressions: today's outflow against the 30-day average, or a transaction amount against the mean plus two standard deviations.
Every aggregation runs over a rolling historical window, scoped per entity, with additional filters on any field the rule references. Because the values are computed live at evaluation, a baseline is never stale: the decision at 14:03 reflects behavior up to 14:03.
Analysts author these in plain language. "Flag when the amount exceeds the customer's 95th percentile over the last 90 days" is a complete, valid control description; the platform turns it into an explainable model an operator reviews before deployment.
What this catches in practice:
- Distribution patterns. A distinct count of beneficiaries over 48 hours exposes an account fanning out to many recipients, the classic mule signature, even when every individual transfer is modest.
- Deviation from self. A transfer above the entity's own average plus two standard deviations flags an anomaly calibrated to that customer, not a global threshold that over-alerts on high-volume accounts and under-alerts on quiet ones.
- Coordinated velocity. Counts and sums over short windows catch bursts; comparing the burst window to a longer baseline window in one expression separates a salary day from an extraction.
- Distributional outliers. A percentile check places a transaction inside the entity's own history, which makes "unusual for this customer" a computable predicate instead of an analyst's hunch.
Stateful aggregations run over transaction history natively. For high-volume activity that is not a transaction, such as login attempts or session events, see Event Counters, which extend windowed signals to arbitrary event streams and feed rules through the same evaluation path.
Governance
A healthy rule lifecycle includes:
- Drafting.
- Peer or maker-checker review.
- Inactive testing.
- Approval for activation.
- Live deployment.
- Monitoring for false positives and missed fraud.
- Periodic retirement or revision.