Implementation overview
This brief describes how the recommended event stream plus state snapshot strategy is implemented in practice using Loci's composable infrastructure, and outlines an initial baseline control set suitable for regulatory-grade deployment. It translates the strategy into concrete implementation guidance, while remaining readable to senior technical, risk, and compliance leaders.
The objective is not maximum coverage on day one, but strong baseline controls, explainability and auditability, low operational overhead, and a foundation that can evolve.
Loci implements this strategy by evaluating every transaction as the primary decision event, enriched by two complementary intelligence layers: recent events and current state.
The data model: four logical surfaces
Loci's implementation does not prescribe a rigid schema. Instead, it recommends a minimal, composable data model that supports regulatory-grade controls while keeping operational overhead low.
Every decision in Loci is anchored on a transaction event, enriched by additional data models that provide behavioral and contextual intelligence at decision time. The model is intentionally separated into four logical surfaces, each with a clear responsibility.
entity_events
| Column | Description |
|---|---|
| entity_id | Account / customer identifier |
| event_type | login, password_reset, beneficiary_add, etc. |
| event_timestamp | Event time |
| channel | web, mobile, api |
| metadata_key | Optional classifier |
| metadata_value | Optional value |
Purpose: temporal reasoning and sequencing.
entity_state
| Column | Description |
|---|---|
| entity_id | Account / customer identifier |
| lifecycle_state | new, active, dormant, reactivated |
| last_activity_at | Most recent activity timestamp |
| is_kyc_verified | Boolean |
| risk_tier | Low / Medium / High |
| country_of_residence | ISO country |
| updated_at | State refresh time |
Purpose: baseline truth at decision time.
entity_facts
| Column | Description |
|---|---|
| entity_id | Account / customer identifier |
| fact_type | avg_txn_30d, tx_count_1h, stddev_14d |
| fact_value | Numeric or boolean |
| window | 1h, 24h, 7d, 30d |
| computed_at | Last computation time |
Purpose: statistical and behavioral context.
How FLM uses these tables
Every FLM control may read events for recent behavior, read state for eligibility and constraints, and read facts for deviation and pattern detection.
All three are evaluated at transaction time by MADIE, producing a single, explainable decision.
Baseline composable set: the initial 12 controls
The following controls provide broad regulatory coverage while remaining operationally lightweight.
| # | Control | Category | Intelligence layer |
|---|---|---|---|
| 1 | Dormant-to-Active Reactivation | Lifecycle Risk | State + Events |
| 2 | Dormant Account High-Velocity Transfers | Lifecycle + Velocity | State + Events |
| 3 | Single Transaction Upper Threshold | Threshold Control | State |
| 4 | Weekly Aggregate Value Threshold | Threshold Control | Facts |
| 5 | Monthly Aggregate Volume Threshold | Threshold Control | Facts |
| 6 | Rapid Beneficiary Addition + Transfer | Sequencing | Events |
| 7 | Historical Amount Deviation | Behavioral Deviation | Facts |
| 8 | Structuring via Low Variance Amounts | Layering / Structuring | Facts |
| 9 | High Velocity Outbound Transfers | Velocity | Events |
| 10 | Pass-Through Behavior Detection | Mule / Pass-through | Facts |
| 11 | New Account Early High-Value Activity | Lifecycle Risk | State + Facts |
| 12 | Geo or Channel Inconsistency | Contextual Risk | State + Events |
Control categories
Operational implications
- For compliance teams: clear logic, clear intent, and regulator-friendly explanations.
- For engineering teams: stable data models, predictable access patterns, and low change cost.
- For the business: faster time to coverage, lower operational burden, and confidence at scale.
Most importantly: new controls can be added without refactoring data models, and existing controls remain stable as the system evolves.
Phased rollout guidance
Phase 1: foundational coverage (day 0-30)
Establish immediate regulatory-grade protection with low operational risk, high explainability, and minimal tuning. These controls are deterministic, easy to explain to regulators, low false-positive risk, and aligned with baseline AML and fraud expectations.
| # | Control | Category | Layers | Why phase 1 |
|---|---|---|---|---|
| 1 | Single Transaction Upper Threshold | Threshold Control | Transaction + State | Mandatory baseline control; regulator-expected |
| 2 | Weekly Aggregate Value Limit | Threshold Control | Transaction + Facts | Captures volume-based abuse early |
| 3 | Monthly Aggregate Volume Limit | Threshold Control | Transaction + Facts | Long-horizon exposure control |
| 4 | Early-Life High-Value Activity | Lifecycle Risk | Transaction + State + Facts | Critical for new accounts |
| 5 | Dormant-to-Active Reactivation | Lifecycle Risk | Transaction + State | Strong signal with low ambiguity |
| 6 | Rapid Beneficiary Add then Transfer | Sequencing | Transaction + Events | High-risk, easy to justify |
Phase 1 outcome: strong baseline fraud and AML coverage, immediate regulator confidence, minimal tuning required.
Phase 2: behavioral and network intelligence (day 30-90)
Detect sophisticated, adaptive abuse patterns that emerge after baseline controls are in place. These controls require behavioral baselines, benefit from historical data, and capture patterns missed by simple thresholds.
| # | Control | Category | Layers | Why phase 2 |
|---|---|---|---|---|
| 7 | Historical Amount Deviation | Behavioral Deviation | Transaction + Facts | Requires baseline history |
| 8 | High-Velocity Outbound Transfers | Velocity | Transaction + Events | Benefits from event tuning |
| 9 | Dormant Account High-Velocity Activity | Lifecycle + Velocity | Transaction + Events + State | Composite behavior pattern |
| 10 | Structuring via Low-Variance Amounts | Layering / Structuring | Transaction + Facts | Statistical signal, needs calibration |
| 11 | Pass-Through Behavior Detection | Mule / Pass-Through | Transaction + Facts | Requires flow observation |
| 12 | Geo or Channel Inconsistency | Contextual Risk | Transaction + Events + State | Needs contextual baselines |
Phase 2 outcome: coverage of advanced fraud and AML typologies, reduced blind spots, improved detection of organized or evolving abuse.
Why phased deployment matters
This rollout strategy avoids early false-positive fatigue, allows data to accumulate naturally, gives teams time to build confidence, and aligns with how regulators expect controls to mature.
It also reinforces Loci's core principle: intelligence should grow with the organization.
Closing
This approach does not attempt to predict every fraud pattern. Instead, it provides a clean intelligence foundation, a regulator-aligned reasoning model, and a scalable path forward.
With Loci, fraud and AML controls become structured intelligence, not accumulated complexity.
See it in your stack
A short technical review of your event and state data, then a controlled pilot on the phase 1 controls.