When a device or identity is compromised, the decisive interval is the gap between compromise and the first fraudulent debit — seconds to minutes. ZEOL™ defines when to lock, what to lock, for how long, and why. Money leaving the account can be restricted. Money entering it never is.
A control that can block a salary credit will never survive its first false positive. A control that pauses outbound transfers for thirty minutes while identity is re-verified usually will. Every ZEOL action is built on this distinction.
Signal collection stays where it is technically and legally feasible — the bank's own app, the bank's transaction layer, the telco identity layer. The bank remains the data fiduciary; ZEOL is a decisioning component that sees signal identifiers and opaque session references only.
Every assessment records the exact library and policy version that produced it — a weight change is a new version and can never silently alter decisions on in-flight traffic. POC weights are design estimates; deploying institutions recalibrate against their own confirmed-fraud data.
Known attack shapes are matched as patterns, because signals seen together carry far more meaning than their additive sum. "Matched PAT-ATO-2" is a statement a fraud analyst, a customer-service script, and an ombudsman response can all be built on. A list of weight increments is not.
Note the deliberate escalation between PAT-ATO-1 and PAT-ATO-2: remote control plus overlay is a probable scam session — a reversible soft lock. Add a notification listener and the attacker can read OTPs, meaning transactions complete with no further victim interaction. The standard escalates to a full outflow lock at exactly that point.
This is the actual v0.2 decision logic — additive baseline, pattern matching, and the split critical overrides — running in your browser. Load a scenario or toggle signals yourself.
Synthetic decision logic for demonstration. No data leaves this page. Weights are uncalibrated design estimates — see Limitations.
It is a state machine with an owner, a clock, and a paper trail. This lifecycle — not the scoring — is what makes the standard consumable by a bank: who can lift a lock, after what verification, with what evidence.
| Release path | Soft lock | Emergency lock | Rationale |
|---|---|---|---|
| CUSTOMER_REAUTH — in-app strong re-auth | Yes | No | If the device is compromised, re-authentication happens on the compromised device. It can never be sufficient to lift an emergency lock — this single rule closes the most obvious attacker workaround. |
| VERIFIED_CHANNEL — call-back / video verification | Yes | Yes | Identity confirmed outside the compromised channel. |
| BRANCH_VERIFICATION — in person | — | Yes | The strongest path, reserved for the strongest lock. |
| FRAUD_OPS_OVERRIDE — analyst, dual control | Yes | Yes | Institutional override with named actor and evidence reference in the audit trail. |
Not all "critical" signals carry equal evidence. The standard's answer to false-positive economics: an emergency lock whose most common trigger is a legitimate SIM upgrade will be switched off by the bank within a quarter.
| Class | Signals | Alone | With any second signal |
|---|---|---|---|
| Standalone critical — signature-confirmed malware | TROJAN_01 MAL_01 | EMERGENCY LOCK | EMERGENCY LOCK |
| Corroborated critical — strong but FP-prone (emulator heuristics misfire on OEM builds; SIM flags fire on legitimate upgrades) | EMU_01 SIM_01 | SOFT LOCK + step-up | EMERGENCY LOCK |
Credibility is the product. What this standard does not claim:
ZEOL v0.2 is open for practitioner review. The reference engine, API contract, and full specification are available for evaluation, and the framework maps onto your existing signal sources — not ours.