Developer documentation

FT AML Platform API

Integrate screening, transaction monitoring, and case management directly into your own systems — submit records, evaluate them against your configured rules, and receive alerts back, without leaving your existing workflow.

Overview

The FT AML API lets your systems talk to the AML Platform directly: push customer or transaction data in, and get screening results, alerts, and case updates back — either by polling or by subscribing to webhooks.

All requests and responses use JSON over HTTPS.
Every request requires a bearer token (see Authentication below).
Endpoints are grouped by the same modules used in the platform itself: Name Screening, Transaction Monitoring, Case Management, and Data Ingestion.

Base URL

https://api.ftaml.example/v1

Format

JSON request and response bodies, UTF-8 encoded

Authentication

Every request must include a bearer token issued to your organization. Contact your account team to generate one.

Authorization: Bearer <api_token>
Content-Type: application/json

Tokens are scoped per environment — use a sandbox token while integrating, and switch to a production token only once your integration is verified.

Core concepts

Two ideas show up throughout the API, carried over directly from how the platform itself works:

Variables

A named, reusable calculation over your data — e.g. count_sender_txns_1_week. Rules reference variables instead of repeating raw logic.

Typologies

The category of suspicious behavior a rule detects (e.g. Smurfing). Every alert the API returns is tagged with the typology that triggered it, so your system knows not just that something fired, but why.

Endpoints reference

Draft — pending verification. These paths and payload shapes are a proposed structure based on the platform's feature set. No confirmed API specification was available while drafting this page — check every path, field name, and status code against the real implementation before this goes live.

Name screening

Method & path	Purpose
POST /screening/manual	Submit a single individual or entity for manual screening
POST /screening/batch	Submit a batch of records for screening
GET /screening/jobs/{jobId}	Check the status of a batch or delta screening job

Transaction monitoring

Method & path	Purpose
GET /variables	List available variables
POST /variables	Create a new variable
GET /typologies	List transaction monitoring typologies (rules)
POST /typologies	Create or update a typology

Case management

Method & path	Purpose
GET /alerts	Query alerts by severity, status, or date
PATCH /cases/{caseId}/disposition	Record an investigation outcome on a case

Data ingestion

Method & path	Purpose
GET /ingestion/watchlist/jobs	List watchlist ingestion job history
GET /ingestion/tms/jobs	List transaction data ingestion job history

Example — manual screening request

POST /screening/manual
Authorization: Bearer <api_token>
Content-Type: application/json

{
  "name": "John Doe",
  "entity_type": "individual",
  "dob": "1985-04-12",
  "citizenship": "GBR"
}

200 OK
{
  "screening_id": "SCR-88213",
  "status": "completed",
  "match_score": 91,
  "matches": [
    { "watchlist_id": "WL-3391", "name": "Jon Doe", "score": 91, "category": "PEP" }
  ]
}

Webhooks

Subscribe to receive alerts as they're generated, instead of polling. Configure your callback URL in Account > Integrations.

Example — alert created

POST <your_webhook_url>
Content-Type: application/json

{
  "event": "alert.created",
  "alert_id": "ALT-55012",
  "typology_id": "TYP-2031",
  "account_id": "ACC-77410",
  "risk_score": 78,
  "severity": "High",
  "sla_deadline": "2026-07-13T09:00:00Z"
}

Retry policy, signing secret, and delivery guarantees: to be confirmed with engineering.

Errors

Failed requests return a JSON error body alongside a standard HTTP status code:

{
  "error": {
    "code": "invalid_request",
    "message": "citizenship must be a valid ISO-3166 country code"
  }
}

Status	Meaning
400	Request was malformed or failed validation
401	Missing or invalid bearer token
404	Resource not found (e.g. unknown job or case ID)
429	Rate limit exceeded — see below
500	Unexpected server error — retry with backoff

Rate limits & versioning

Default rate limits and API version deprecation policy: to be confirmed with engineering before publishing.