Aelix Guardian · Fraud detection and AML
Financial-crime operations you can prove, inside your own perimeter.
Aelix Guardian is a single-tenant, on-prem-first AML, KYC, KYB, and SAR platform. Trained models score transactions and entities from your data, real sanctions screening runs against a public OFAC list, and every alert flows to a case and a SAR, in workflows designed to support BSA/AML and FinCEN reporting. All behind one auditable system that never leaves your network.
Aelix Agents · Agentic AI
An agentic layer over financial-crime ops.
Guardian now includes an agentic layer. Autonomous, tool-using agents that act through Guardian's governed APIs, do the routine compliance work, and escalate the judgment calls to a human. Every agent is human-in-the-loop by default, runs inside your perimeter, and writes each step to the same append-only audit trail as the rest of the platform.
Alert Triage Agent.
Enriches a financial-crime alert with the entity graph, sanctions screen, and transaction history, then recommends close, escalate, or file.
SAR Drafting Agent.
Assembles the narrative and maps FinCEN fields from the case, leaving sign-off and signature to the BSA officer.
KYC Remediation Agent.
Works periodic-review and refresh gaps, requesting documents and re-screening on a schedule.
Agents act only through permissioned, least-privilege APIs. They never close an alert, file a SAR, or auto-clear a refresh without a credentialed human's sign-off, and the BSA officer's signature still stands on every filing. The reasoning model is a swappable component: run a local model on-prem for full data residency, or a hosted model where policy allows.
The problem
A compliance tax on two fronts. Most teams pay both.
Financial-crime compliance has become a tax on two fronts at once, and most teams pay both.
Tool sprawl.
Detection lives in one system, screening in another, KYB and UBO mapping in a third, and SAR filing in a spreadsheet-and-PDF process bolted onto the end. Analysts swivel between consoles, and evidence scatters across them.
Detection you cannot stand behind.
“AI-powered” alerting too often turns out to be a handful of hardcoded rules or seeded demo data. When an examiner asks what fired an alert (and why), there is no honest answer.
Data residency you cannot honor.
Cloud-only AML suites ask you to ship customer PII, transaction histories, and beneficial-ownership records into someone else's tenancy. For sovereignty-bound and air-gapped institutions, that is a non-starter.
Guardian is built to close all three at once. Single-tenant, inside your walls, with detection that is real and measurable rather than a slide.
Available today
Shipped, running code. Detection that is computed, not seeded.
Computed detection: real trained models, not seeded demo data
At the core of Guardian are two real, trained ML models behind a stable scoring interface. A gradient-boosted classifier scores transaction fraud (structuring bands, high-risk corridors, dispersion, above-CTR cash, velocity). A calibrated classifier scores entity / KYC risk from aggregate behavior and sanctions exposure. Scores are computed from your actual Transaction and Entity rows. The detection pass aggregates each entity's history, scores every transaction, flags the ones over threshold, recomputes the entity's risk score, and raises an alert from the strongest signal. The alert you see was computed from the data underneath it.
Precision, recall, and F1 are recorded in a versioned model card, and performance is validated on your own labeled activity during deployment.
Real sanctions and PEP screening
Screening runs against sanctions and PEP screening lists, including the public OFAC SDN list. Names are normalized (case, diacritics, legal-suffix and honorific stripping) and matched with token-overlap plus fuzzy sequence similarity to produce a confidence score and a clear match status (no match, potential, confirmed). A DOB corroboration step nudges confidence where it lines up. Commercial sanctions and PEP data providers connect through a pluggable adapter behind the same interface, which fails closed, so it never fabricates a result.
UBO and money-flow graphs from real rows
Guardian's entity graph is traversed from your database, not drawn from fixtures. Ownership mode walks the KYB application's beneficial owners and directors, screens each node, and flags ownership above the 25% disclosure threshold and any sanctions/PEP hits. Transaction mode aggregates an entity's real counterparties by volume, screens them, and flags flows to sanctioned parties or high-risk (FATF) jurisdictions. When there is no data for an entity, the graph is honestly small. Never an invented scenario.
One workflow: alert to case to signed SAR
Detection raises an alert with a model explanation and the transactions that drove it. Analysts triage it, open and assign a case, and compose a SAR. Guardian auto-maps FinCEN fields from the narrative, then renders a BSA E-Filing v2.4 SAR XML envelope. On sign-off, an authorized signer applies a SHA-256 signature, the XML is generated and stored, and the filing is downloadable for submission. One queue, one case, one filing. No swivel chair.
On-prem isolation as the default
Guardian is single-tenant and on-prem-first. It deploys inside the institution's own perimeter, supports air-gapped installs with internal-CA certificates, and keeps admin surfaces reachable only over your network. Your data never leaves your walls. And the platform is cloud-portable later, per service, without a rewrite.
Audit and access control, by construction
Every state-changing request lands in an append-only audit log written in the same transaction as the change it records. Actor, role, resource, outcome, and a structured diff. Access is governed by role-based controls for the roles compliance teams actually run. Fraud investigator, BSA officer, IT auditor. With MFA and OIDC authentication. The evidence an examiner asks for is a byproduct of normal operation, not a separate project.
How it works
One continuous flow from raw activity to a filed report.
01
Transactions and entities land.
In the platform through onboarding (KYC) and business onboarding (KYB, with beneficial owners and directors).
02
Detection scores the data.
The trained models compute a transaction-fraud score for each transaction and an entity-risk score from aggregate behavior and sanctions exposure.
03
Alerts are raised from the signal.
The strongest scored transaction over threshold becomes an alert, carrying its model explanation and the transactions behind it.
04
Analysts work the case.
Triage the alert, open and assign a case, pull up the UBO or money-flow graph, and screen names against the sanctions list.
05
A SAR is composed, signed, and exported.
FinCEN fields auto-map from the narrative, the SAR renders to BSA E-Filing XML, an authorized signer applies a SHA-256 signature, and the filing is downloaded for submission.
06
Everything is logged.
Each consequential action writes to the append-only audit log, feeding oversight and examiner evidence.
Proof, framed honestly
Mechanisms you can verify. Numbers framed with their conditions.
Trained transaction-fraud and entity-risk models.
Real pipelines, with metrics recorded in a versioned model card and validated on your data.
Scored in well under 1ms.
Single-transaction scoring latency, measured (p50/p95/p99) by a reproducible benchmark. Not asserted.
Real OFAC SDN screening.
A public list, normalized, with token plus fuzzy matching and a confidence score. Not a handful of hardcoded names.
Graphs from real rows.
UBO and money-flow graphs traversed from your KYB and transaction data.
Append-only audit.
Every state change recorded in-transaction, with RBAC, MFA, and OIDC.
What we deliberately do not print
We deliberately do not print accuracy or detection-speed slogans as facts. The mechanisms above are what the code does, and performance is measured on your data.
Security and compliance
Engineered for the buyer whose data is not allowed to leave the building.
Guardian is engineered for regulated financial-crime operations from the ground up.
SOC 2-aligned controls.
Role-based access control across compliance roles, MFA and OIDC authentication, and an append-only audit log written in the same transaction as every state change.
Designed to support GDPR.
Built for institutions under strict data-handling obligations, with PII held inside your own perimeter rather than a shared cloud tenancy.
Data residency as a strength, not a checkbox.
Single-tenant, on-prem-first deployment with air-gapped support and internal-CA certificates means sovereignty and residency requirements are satisfied by architecture, not by promise. Cloud-portable later, per service, without a rewrite.
SOC 2-aligned controls. SOC 2 Type II and ISO 27001 audits planned.
See Guardian on your workflow
See Guardian on your own compliance workflow.
Bring your transactions, your entities, and your screening requirements. We will show you a computed alert with its model explanation, a real sanctions match, a UBO graph traversed from data, and a signed SAR XML. End to end, on real working software, inside your perimeter.
Frequently asked
Questions compliance teams ask in the second meeting.
Is the fraud scoring real ML, or seeded demo data?
Real ML. Guardian runs two trained ML models (a gradient-boosted transaction-fraud classifier and an entity-risk classifier) that compute scores from your actual transaction and entity rows. Alerts and risk scores are derived by the detection pass, not hardcoded in seed data. Full metrics are recorded in a versioned model card and validated on your data during deployment.
Do you screen against real sanctions lists?
Yes. Screening runs against sanctions and PEP screening lists, including the public OFAC SDN list, with name normalization (case, diacritics, legal-suffix and honorific stripping) and token-plus-fuzzy matching that returns a confidence score and match status. Commercial sanctions and PEP data providers connect through a pluggable adapter that fails closed. It never fabricates a live result.
Which regulatory regimes does Guardian support?
Guardian is designed to support BSA/AML and FinCEN reporting workflows for US institutions, and RBI KYC master direction and FIU-IND STR reporting workflows for Indian banks and PA/PG fintechs. Models detect AML typologies such as structuring bands, high-risk corridors, dispersion, and velocity, and are validated on your own labeled activity during deployment.
Can we deploy this without our data leaving our network?
Yes. Guardian is single-tenant and on-prem-first. It installs inside your own perimeter, supports air-gapped deployment with internal-CA certificates, and keeps admin surfaces on your network. It is cloud-portable later, per service, if and when you choose. Without a rewrite.
Can we file SARs from Guardian today?
You can compose, sign, and export them. Guardian auto-maps FinCEN fields from the narrative, renders a BSA E-Filing v2.4 SAR XML envelope, applies a SHA-256 signature on sign-off, and lets an authorized signer download the filing for submission through your institution’s BSA E-Filing account.
Need this tailored to your environment?
Every Aelix product can be configured, extended, or built bespoke for your industry, data sources, and compliance constraints. Talk to our engineers about what would change.
Configurable workflows
Adapt rules, thresholds, and approval flows to match your operational policies.
Custom data integrations
Connect to your specific ERP, MES, SCADA, CRM, or proprietary systems.
Bespoke modules
Build product extensions tailored to your industry, region, or compliance needs.