Flagright
AML operations and AI review
Flagright brings transaction monitoring, dynamic customer risk, watchlist screening, case workflows, and AI Forensics into a shared compliance environment. The product emphasizes configurable rules and review operations. Its current materials distinguish live decisioning, shadow testing, and AI-assisted investigation.
Our assessment
AML, screening, AI review, and filing tools. Confirm identity and underwriting needs outside this core stack.
Best fit and limitations
A relevant candidate for fintechs and payment firms that want AML teams to configure controls and reduce repetitive case work. Compare the full operating cost against separate monitoring, screening, and case products.
- Monitoring fraud patterns is not proof of a complete device intelligence or card authorization system.
- Filing coverage figures differ across current pages. Confirm each regulator, report format, and direct submission versus export path.
- Vendor automation percentages are claims, not results measured on your portfolio.
Tools 6
Transaction MonitoringDetection and rule management+
- Natural-language rule creation and scenario configuration
- Historical simulation and live shadow mode
Dynamic risk scoringCustomer context+
- Use KYC, behavior, and transaction history
- Apply monitoring thresholds by risk level
Watchlist ScreeningCustomer and payment checks+
- Sanctions, PEP, adverse media, and internal lists
- Onboarding and ongoing screening workflows
Case and workflow orchestrationReview operations+
- Route alerts and cases to people or agents
- Configure escalation and investigation steps
Regulatory FilingReporting and submission+
- SAR, STR, CTR, and TTR workflows with supervisor approval
- Direct submission for supported regulators; filing packages for other supported jurisdictions
AI Forensics + AI EngineAutomated review+
- Evidence collection and investigation narratives
- Screening and monitoring agents with source context
AI capabilities
Rule assistance + investigation agents
AI Forensics supports transaction and screening review. Published controls include modes from silent evaluation to more automated handling, with explanation and version information.
What to validate
Test silent mode first. Examine the evidence for cleared alerts, reopen behavior, approval rules, and exportable decision history.
Implementation
Integration checklist
- Validate entity and transaction APIs, processing modes, and data completeness.
- Test rules against your own history, then shadow the production stream.
- Define hold/release responsibility and the authority of automated case actions.
Commercial scope
Quote required. Request monitoring, screening, AI review volume, case users, support, data residency, and setup costs.
Questions for the demo
- How does an agent show evidence for a false-positive clearance?
- Can our team backtest, approve, deploy, and roll back a rule?
- Which reporting and list-data services are included?
Engineering
- Inputs
- Names, dates of birth, selected list data, and configurable matching settings · Customer transaction history, behavioral baselines, and counterparty relationships · Transaction history, accounts, entities, counterparty context, and screening results · Raw request body and the endpoint-specific signing secret · Case evidence, institution policies, and analyst corrections
- Outputs
- Transaction, user, case, alert, rule-action, and SAR lifecycle notifications · Approved filings through supported regulator APIs, or filing packages where direct submission is unsupported · Anomaly findings, peer-deviation alerts, and counterparty clusters · Multi-hop fund traces and relationship clusters for investigation · HTTPS JSON events with id, type, data, and millisecond createdTimestamp · User/transaction changes, alert/case events, and SAR lifecycle notifications · HMAC-SHA256 hex signature matched against X-Flagright-Signature · Configured risk-level, risk-score, or any-risk-change notifications · FRAML and Management OpenAPI specifications · Official TypeScript/Node, Python, Java, and Go clients · Validated narratives, confidence scores, and exportable evidence/action records
- Webhooks
- HTTPS endpoints receive JSON event payloads, including changes to cases, alerts, and regulatory report status. Return 2xx before the 10-second timeout. The guide describes retries for 3xx/4xx/5xx responses for up to three days, then failure. Changes caused directly by an API call are returned in that API response. Non-API changes can trigger risk webhooks.
- Decision timing
- No measured latency or contracted response time verified.
- Deployment
- Published production webhook origins include Oregon, Frankfurt, London, Ireland, Singapore, Hong Kong, Sydney, and UAE
- Dependencies
- Client-operated HTTPS webhook endpoint · Human approval in the filing lifecycle · Configure edit-distance, phonetic, transliteration, token, and date-tolerance rules for the intended population · Validate new monitoring policies with historical backtests and shadow alerts before activation · Register a publicly reachable HTTPS endpoint and selected event types · Retrieve each endpoint's secret from Console settings · Accept any valid comma-separated signature during secret rotation · Choose the correct API surface and environment before generating or configuring a client · Configured automation levels, approvals, permissions, retention, and residency controls
Verified details 32
- Outputs
Transaction, user, case, alert, rule-action, and SAR lifecycle notifications
Source Checked 2026-09-18 - Webhooks
HTTPS endpoints receive JSON event payloads, including changes to cases, alerts, and regulatory report status.
Source Checked 2026-09-18 - Dependency
Client-operated HTTPS webhook endpoint
Source Checked 2026-09-18 - Outputs
Approved filings through supported regulator APIs, or filing packages where direct submission is unsupported
Source Checked 2026-09-18 - Dependency
Human approval in the filing lifecycle
Source Checked 2026-09-18 - Inputs
Names, dates of birth, selected list data, and configurable matching settings
Source Checked 2026-09-18 - Connected provider
OpenSanctions
Source Checked 2026-09-18 - Connected provider
KYC6
Source Checked 2026-09-18 - Connected provider
Customer-supplied risk data feeds
Source Checked 2026-09-18 - Dependency
Configure edit-distance, phonetic, transliteration, token, and date-tolerance rules for the intended population
Source Checked 2026-09-18 - Inputs
Customer transaction history, behavioral baselines, and counterparty relationships
Source Checked 2026-09-18 - Outputs
Anomaly findings, peer-deviation alerts, and counterparty clusters
Source Checked 2026-09-18 - Dependency
Validate new monitoring policies with historical backtests and shadow alerts before activation
Source Checked 2026-09-18 - Inputs
Transaction history, accounts, entities, counterparty context, and screening results
Source Checked 2026-09-18 - Outputs
Multi-hop fund traces and relationship clusters for investigation
Source Checked 2026-09-18 - Outputs
HTTPS JSON events with id, type, data, and millisecond createdTimestamp
Source Checked 2026-09-18 - Outputs
User/transaction changes, alert/case events, and SAR lifecycle notifications
Source Checked 2026-09-18 - Dependency
Register a publicly reachable HTTPS endpoint and selected event types
Source Checked 2026-09-18 - Webhooks
Return 2xx before the 10-second timeout. The guide describes retries for 3xx/4xx/5xx responses for up to three days, then failure.
Source Checked 2026-09-18 - Deployment
Published production webhook origins include Oregon, Frankfurt, London, Ireland, Singapore, Hong Kong, Sydney, and UAE
Source Checked 2026-09-18 - Inputs
Raw request body and the endpoint-specific signing secret
Source Checked 2026-09-18 - Outputs
HMAC-SHA256 hex signature matched against X-Flagright-Signature
Source Checked 2026-09-18 - Dependency
Retrieve each endpoint's secret from Console settings
Source Checked 2026-09-18 - Dependency
Accept any valid comma-separated signature during secret rotation
Source Checked 2026-09-18 - Outputs
Configured risk-level, risk-score, or any-risk-change notifications
Source Checked 2026-09-18 - Webhooks
Changes caused directly by an API call are returned in that API response. Non-API changes can trigger risk webhooks.
Source Checked 2026-09-18 - Outputs
FRAML and Management OpenAPI specifications
Source Checked 2026-09-18 - Outputs
Official TypeScript/Node, Python, Java, and Go clients
Source Checked 2026-09-18 - Dependency
Choose the correct API surface and environment before generating or configuring a client
Source Checked 2026-09-18 - Inputs
Case evidence, institution policies, and analyst corrections
Source Checked 2026-09-18 - Outputs
Validated narratives, confidence scores, and exportable evidence/action records
Source Checked 2026-09-18 - Dependency
Configured automation levels, approvals, permissions, retention, and residency controls
Source Checked 2026-09-18
Illustrative contract
An example for your internal adapter. This is not a vendor endpoint, request, or response.
{
"contract": "internal-risk-review/v1",
"vendorId": "flagright",
"internalCorrelationId": "example-001",
"vendorRecordId": null,
"control": "Detection and rule management",
"evidence": [],
"status": "pending",
"decision": "review",
"requiresHumanReview": true
}Integration limits
- Illustrative internal integration contract. This is not a vendor request, response, endpoint, or SDK example.
- Empty country, deployment, or provider lists mean not verified in this review. A documented country refers to the specific product noted in its source, not universal platform coverage.
- This introductory page does not establish retry counts, ordering, or authentication guarantees. Verify those before accepting production events.
- The page does not enumerate a named regulator and interface for every jurisdiction. Broad filing coverage is not enough to pass this site's strict direct-filing filter.
- Matching settings are not calibrated fraud probabilities. Connected data feeds have separate scope and rights.
- The page describes ML detectors but does not provide independently validated detection or false-positive benchmarks.
- This establishes transaction-network analysis, not complete corporate ownership discovery.
- A regulator-related event type does not establish universal direct filing coverage.
- Confirm timeout-specific failure behavior and replay recovery during integration. These are source-IP locations, not customer screening coverage.
- Each endpoint has its own secret. Do not verify a reserialized payload or assume a common secret across endpoints.
- Examples include manual overrides, risk locks, SAR-related recalculation, and list/PEP updates. API callers must inspect the response instead of waiting for a duplicate webhook.
- Generated results remain reviewable, editable, and overridable. Incomplete evidence lowers confidence or triggers review. The page does not publish the supported model/provider matrix.
Sources 10
Source review dates are shown above. Product claims come from public sources. Fit, limits, and evaluation questions are our analysis. This is not a hands-on performance test. Methodology · Changelog