FT AML Platform
Developer Portal

Cover Page

The formal front matter for this Developer Guide, provided for enterprise procurement, audit, and archival purposes. This section does not affect the technical content below — skip to Introduction to start integrating.

Document Control

Version history, review, and approval tracking for this guide. Populated as the guide moves through formal review cycles.

Version history

Reviewers & approvers

Change log

A running log of substantive content changes to this guide (distinct from the API/product changelog, which tracks changes to the platform itself).

Table of Contents

A linear index of every section in this guide, generated from the sidebar navigation on the left. Use the sidebar for day-to-day navigation — this section exists for printed/exported copies where the sidebar isn't available.

Generating…

Introduction

This Developer Portal is the integration reference for the FT AML Platform. It is written for customers connecting core systems, partners building integrations, and Fyscaltech implementation teams delivering go-live solutions.

What FT AML does

FT AML is an Anti-Money Laundering (AML) platform that helps financial institutions detect suspicious activity, screen customers against regulatory watchlists, perform callback name screening, monitor transactions, and manage compliance investigations.

Integration Capabilities

• Bulk upload via S3 — Explicitly supported for loading or refreshing large volumes of Customer, Account, Transaction, and Watchlist datasets into FT AML via AWS S3.

• Customer Ingestion API — For pushing real-time customer record updates from core systems.

• Screening API — For on-demand screening of names against sanctions and watchlist databases.

• Callback Name Screening — Asynchronous name screening with automated callback event delivery.

• API Callback Integration — Capability to integrate Fyscaltech-provided API callbacks for automated status and alert notifications.

Who does what

Customers

Provide source data (Customer, Account, Transaction, Watchlist) via API key or AWS access.

Partners

Build integrations using provided API callbacks and S3 bulk upload pathways.

Implementation teams

Fyscaltech engineering team delivering provisioning, API key issuance, and access setup.

This portal

The shared single source of truth for all FT AML platform integration specifications.

System Requirements

FT AML is delivered as a hosted (SaaS) platform. Requirements focus exclusively on client-side connectivity, firewall settings, and network prerequisites.

What you need on your side

Firewall & SSL requirements

• Allow outbound HTTPS (443) to FT AML API hostnames with IP whitelisting active.

• Allow outbound HTTPS to AWS S3 bucket regions for Bulk upload via S3.

• TLS 1.2+ certificate validation required.

Prerequisites

Everything you should have in place — or in progress with your Fyscaltech contact — before you start building against any of the integration methods.

Access & Prerequisites

• Access Provisioning — API key or AWS access are the ways customers will be given access by Fyscaltech during onboarding.

• Outbound Network Access — IP whitelisting in Outbound Network Access is required as a mandatory prerequisite for connecting to FT AML endpoints.

Network & DNS

• Standard public DNS resolution to Fyscaltech-provided hostnames.

• Outbound network access requires IP whitelisting on port 443 (HTTPS).

• If receiving webhooks/callbacks, provide a publicly reachable HTTPS endpoint with a valid DNS name and TLS 1.2+ certificate.

Third-party software

• AWS CLI / S3 SDK — For Bulk upload via S3.

• An HTTP client capable of TLS 1.2+ — For Customer Ingestion API and Screening API calls. Plain JSON over HTTPS.

Quick Start

If you're an external developer integrating FT AML into your own systems for the first time, this is the one section to read start to finish — everything else in this portal is reference material you'll come back to as you go.

Six-step onboarding flow

The fastest path from zero to a working integration follows the same six steps regardless of which integration method you end up using day to day.

• Request API credentials — contact the Fyscaltech integration team (see Support) to start onboarding. They'll confirm which integration method(s) fit your use case.

• Receive Non-Production access — where a Non-Production testing environment applies to your chosen method, credentials and connection details are issued as part of onboarding (see Validation Checklist).

• Upload a sample customer — load a small test file via Bulk upload (50–100 rows is plenty), or a single record via the Customer Ingestion API, to confirm your data format is accepted.

• Call the Screening API — submit a customer's full name to /screen and confirm a result comes back in the response.

• Check the delivery mechanism for ingestion-triggered screening — if you plan to rely on name_screening_enabled during ingestion instead of calling the Screening API directly, confirm with Fyscaltech how that result reaches you before building against it.

• View the screening result — check the FT AML console (Alert Manager, or Name Screening) to see the same result reflected on the platform side.

Where to start

If you're not sure which integration method fits your volume and timeline, read Integration Methods and the "Which one should I use?" table first — then bring that shortlist to the Fyscaltech integration team.

Installation Guide

FT AML is a hosted (SaaS) platform. This guide documents the setup steps required on your side to connect and verify reachability.

Step 1 — Request access

Objective: Obtain access credentials from Fyscaltech.

Customers will be given access via API key or AWS access during onboarding. Contact Fyscaltech implementation teams to receive your credentials.

Step 2 — Set up the AWS CLI (Bulk upload via S3)

Objective: Authenticate AWS CLI or S3 SDK for file uploads.

aws configure

Validation:

aws s3 ls s3:////

Common error. Access Denied on this command almost always means the client id in the path doesn't match the one issued to you, credentials belong to a different environment (Non-Production vs. Production), or the path itself may be incorrect.

Step 3 — Confirm API reachability

Objective: Verify network reachability to active API endpoints over HTTPS. These connectivity tests confirm end-to-end transport and authentication readiness.

A. Customer Ingestion API Reachability

Submit a test reachability request to the Customer Ingestion API:

{
  "request": "POST /riskradar/core/api/v1/customers",
  "headers": {
    "Content-Type": "application/json",
    "X-API-Key": "YOUR_NON_PROD_API_KEY"
  },
  "body": {
    "customer_id": "TEST-PING-001",
    "customer_name": "Connectivity Test",
    "name_screening_enabled": false
  }
}

Expected 200 OK Response:

{
  "code": "00000",
  "message": "Success",
  "data": {
    "customer_id": "TEST-PING-001",
    "status": "ACTIVE"
  }
}

B. Screening API Reachability

Submit a test reachability request to the active Screening API endpoint:

{
  "request": "POST /riskradar/core/api/v1/screen",
  "headers": {
    "Content-Type": "application/json",
    "X-API-Key": "YOUR_NON_PROD_API_KEY"
  },
  "body": {
    "customer_name": "Test User",
    "threshold": 0.8
  }
}

Equivalent curl verification:

curl -i -X POST https://api.ft-aml.fyscaltech.com/riskradar/core/api/v1/screen \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_NON_PROD_API_KEY" \
  -d '{"customer_name": "Test User", "threshold": 0.8}'

Expected 200 OK Response:

{
  "code": "00000",
  "message": "Success",
  "data": {
    "screening_id": "SCR-PING-001",
    "matches_found": 0,
    "results": []
  }
}

Step 4 — Verification checklist

• AWS CLI (or SDK) authenticates and lists your client-id S3 path — Bulk upload path

• Test HTTPS call to active Screening API endpoint returns valid JSON response

• Environment (Non-Production or Production) confirmed with Fyscaltech

Configuration Guide

Configuration guidance for FT AML integrations.

Environments

FT AML operates under exactly two environments:

• Non-Production — Dedicated Non-Production environment for integration development, testing, and staging.

• Production — Live production environment for active customer ingestion, transaction monitoring, and screening.

Core Concepts

Fundamental domain concepts used throughout the FT AML Platform.

Customer Records

Individual or entity profiles tracked for AML risk assessment and screening.

Watchlist

Watchlists represent collections of sanctioned entities, Politically Exposed Persons (PEPs), and custom high-risk individual/entity lists. Customers can bring their own custom watchlist or integrate compatible global list datasets, such as LSEG (London Stock Exchange Group) and other standard provider lists.

Alerts & Cases

Screening and transaction monitoring matches generate alerts that compliance analysts review in the FT AML Console.

Integration Methods

Which one should I use?

Choose Bulk upload via S3 for batch processing datasets, or the Customer Ingestion API and Screening API for real-time customer updates and on-demand screening. API Callback integration handles asynchronous screening events.

Bulk data ingestion (CSV via S3)

Getting access

Access is provisioned via AWS access (S3 bucket & credentials) or API key by Fyscaltech.

Ingestion Mode

Bulk CSV ingestion operates without a fixed schedule. Files uploaded to designated S3 folders are automatically ingested and processed upon upload.

Screening Integration

Ingested customer data automatically triggers screening against active watchlists and sanctions databases as part of the ingestion pipeline.

Build Your Integration

This section details where and how to upload data for each core domain within FT AML:

1. Where to upload Customer data

Upload Customer profile CSV files to your designated S3 bucket customer directory:

s3:////customer/customer_.csv

2. Where to upload Account data

Upload Customer Account CSV files to your designated S3 bucket account directory:

s3:////account/account_.csv

3. Where to upload Transaction data

Upload Transaction CSV files to your designated S3 bucket transaction directory:

s3:////transaction/transaction_.csv

4. Where/how to upload Watchlist data

Upload custom or third-party Watchlist datasets to your designated S3 bucket watchlist directory:

s3:////watchlist/watchlist_.csv

Watchlist Data Specifications: Customers can bring their own custom watchlist or use compatible industry list providers. FT AML supports standard watchlist lists, including LSEG (London Stock Exchange Group) and other compatible screening provider formats.

Endpoint for real-time customer profile creation and modification.

Request Payload

{
"customer_id": "CUST-10029",
"customer_name": "Jane Doe",
"dob": "1985-04-12",
"country": "US",
"name_screening_enabled": true
}

Validation Rules

• customer_id — Required string. Unique customer identifier.

• customer_name — Required string. Non-empty.

• dob — Optional ISO date format (YYYY-MM-DD).

• country — Optional 2-letter ISO country code.

API Status Codes

Active Endpoint: POST /riskradar/core/api/v1/screen

Performs real-time fuzzy name matching against sanctions, PEPs, and watchlists.

Request Payload

{
"customer_name": "John Smith",
"threshold": 0.8,
"include_pep": true
}

Response Envelope

{
"code": "00000",
"message": "Success",
"data": {
"screening_id": "SCR-99482",
"matches_found": 1,
"results": [
{
"entity_name": "John Smith",
"score": 0.92,
"matched_list": "LSEG World-Check / Sanctions"
}
]
}
}

Authentication

Authentication and authorization for FT AML platform access.

Token-passing information and authentication credentials will be provided directly by Fyscaltech during onboarding.

API Key authentication

• API Key Access — For Customer Ingestion API, Screening API, and API callback integration. Token-passing details provided by Fyscaltech.

AWS S3 credentials

• AWS Access — S3 bucket access credentials provided by Fyscaltech for Bulk upload via S3.

Integration Workflows

There are two distinct request patterns depending on which APIs you use — a synchronous flow where the screening result comes back in the same response, and an asynchronous flow where it's delivered later to your webhook.

Flow A — synchronous (Screening API called directly)

Flow B — asynchronous (ingestion-triggered screening)

The Customer Ingestion API accepts a name_screening_enabled field (defaulting to true when omitted), so ingesting a customer can trigger screening as a side effect rather than requiring a separate call to the Screening API. Results land on your webhook endpoint as processing completes.

Bulk upload — batch (sits outside both flows)

Bulk upload uploads are for getting Customer, Customer Account, and Customer Transaction data into the platform in volume, rather than triggering an immediate screening result back to your system. Screening or monitoring against that data happens on the platform's own schedule (see Name Screening's Batch and Delta Screening, and Transaction Monitoring's execution intervals) rather than as a direct response to the upload.

Choosing sync vs. async

Webhooks & Events

Real-time asynchronous notification delivery for screening hits, batch ingestion status, and alert updates.

Webhook Architecture

When asynchronous operations complete (such as ingestion-triggered screening or S3 bulk file parsing), the FT AML platform sends an HTTP POST request with a JSON payload to your registered webhook listener URL.

Supported Event Types

Sample Event Payload (screening.match_found)

{
  "event_id": "evt_991823014",
  "event_type": "screening.match_found",
  "timestamp": "2026-09-02T16:05:00Z",
  "data": {
    "screening_id": "SCR-99482",
    "customer_id": "CUST-10029",
    "customer_name": "Jane Doe",
    "matches_found": 1,
    "max_score": 0.95,
    "top_match": {
      "entity_name": "Jane Doe",
      "score": 0.95,
      "matched_list": "OFAC Specially Designated Nationals"
    }
  }
}

Signature Verification (HMAC-SHA256)

To verify that webhook requests originate from FT AML and have not been tampered with, inspect the X-FT-Signature and X-FT-Timestamp HTTP headers.

Node.js / JavaScript Verification Example

const crypto = require('crypto');

function verifyWebhook(payloadRaw, signatureHeader, timestampHeader, secret) {
  const signedPayload = `${timestampHeader}.${payloadRaw}`;
  const expectedSig = crypto
    .createHmac('sha256', secret)
    .update(signedPayload, 'utf8')
    .digest('hex');
  return crypto.timingSafeEqual(Buffer.from(signatureHeader), Buffer.from(expectedSig));
}

Python Verification Example

import hmac, hashlib

def verify_webhook(payload_raw, signature_header, timestamp_header, secret):
    signed_payload = f"{timestamp_header}.{payload_raw}".encode('utf-8')
    expected_sig = hmac.new(secret.encode('utf-8'), signed_payload, hashlib.sha256).hexdigest()
    return hmac.compare_digest(signature_header, expected_sig)

Errors, Limits & Best Practices

Error codes, handling strategies, and platform error responses.

Business Error Codes

Validation Checklist

Complete this checklist to verify your integration before go-live.

General checklist

• API key or AWS access credentials received from Fyscaltech.

• IP whitelisting configured for Outbound Network Access.

• Bulk upload via S3 paths verified for Customer, Account, Transaction, and Watchlist datasets.

• Active Screening API endpoint (/screen) verified with test JSON payload.

• API callback integration configured and callback name screening verified.

Environment verification

• Non-Production and Production environment separation confirmed with Fyscaltech.

Security Best Practices

Security standards for integrating with the FT AML platform.

Secrets Management

• Store API keys and AWS credentials in secure secrets managers.

• Never embed credentials in client-side or browser-based code.

Transport & Certificates

• Enforce TLS 1.2 or higher for all API and S3 connections.

• Validate server TLS certificates.

Access Control & Least Privilege

Access control information, IAM policy specifications, and role permission details will be provided directly by Fyscaltech.

FAQ & Glossary

Common issues

Frequently asked questions

Can we use more than one integration method at once?

Yes — most institutions use Bulk upload for the initial customer population, then the Customer Ingestion API and/or Screening API for ongoing, real-time updates.

Do we need a webhook if we only use the Screening API?

No. Calling the Screening API directly returns the result in the same response — a webhook is only needed for the ingest-then-screen flow via the Customer Ingestion API.

Is there a Non-Production environment we can test against before going live?

Yes — access to the Non-Production Environment is provisioned during onboarding for staging and integration testing (see Validation Checklist).

Can the Screening API match on more than full name?

Not currently — it supports full name matching only. Additional matching fields (date of birth, address, citizenship) are available through Manual Screening in the console today.

Where do we find upcoming API changes before they land?

Keep a point of contact with the Fyscaltech integration team, and check Resources & Changelog once a public changelog is published.

What happens if I upload a Bulk upload file with the wrong header?

The entire file is rejected and moved to rejected/customer/ or rejected/account/ — no rows are processed. Copy the header line exactly from Bulk data ingestion (upload via S3) rather than retyping it.

Is the Customer Ingestion API synchronous or asynchronous?

Asynchronous. It returns 202 Accepted immediately after validating and publishing an event — the actual database write happens moments later via a background consumer, not within the request. See Customer Ingestion API.

Do I need to install anything to integrate with FT AML?

No. FT AML is a hosted platform — there's no server software to install on your side. See Installation Guide for the (lightweight) one-time setup that applies instead.

Acronyms

Glossary

Terms and field names used throughout this Developer Portal, defined for anyone integrating for the first time.

Resources & Changelog

Downloadable and reference materials to speed up integration work. Anything not yet available will be published soon once received from technical team.

OpenAPI Specification

Machine-readable spec for generating clients or importing into your own API tooling. Will be published soon once received from technical team.

Pending

Upload Templates

The exact Customer and Account file headers are already documented in full under Bulk upload via S3 — copy them directly from there.

Available

Release Notes

A running log of platform and API changes. Will be published soon once received from technical team.

Pending

SDKs

Official client libraries for common languages, planned for a future release.

Future

Fyscaltech Integration Team

The most reliable resource today — see Support for contact details.

Changelog & versioning

As the Customer Ingestion and Screening APIs move from onboarding-provided specifications toward a stable published reference, changes will be communicated directly by the Fyscaltech integration team. If you're integrated against either API, keeping a point of contact with the team (see Support) is the most reliable way to hear about upcoming changes before they land.

Support

• In-app: Homepage > Help & Support

• Email: hello@fyscaltech.com

• Phone: +65 8080 5424

• Headquarters: Singapore · 68 Circular Road

• Account-level issues (API key provisioning, permissions) — contact your organization's Admin

What to include when you contact us

To help us resolve integration issues quickly, please include: the environment (Non-Production/Production), the endpoint and HTTP method, the X-Request-Id from the response headers if available, and a timestamp of when the issue occurred.

Thank you for building on FT AML.