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.

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.
• API Callback Integration — Capability to integrate Name Screening API and Customer Ingestion API.

Who does what

System Requirements & Prerequisites

FT AML is delivered as a hosted (SaaS) platform. Requirements and prerequisites focus on client-side connectivity, firewall settings, access provisioning, network configuration, and third-party software.

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.

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 — 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.

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.

1. Request API credentials — contact the Fyscaltech integration team (see Support) to start onboarding. They'll confirm which integration method(s) fit your use case.
2. Receive non-prod access — where a non-prod/test environment applies to your chosen method, credentials and connection details are issued as part of onboarding (see Testing & non-prod).
3. 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.
4. Call the Screening API — submit a customer's full name to /screen and confirm a result comes back in the response.
5. 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.
6. View the screening result — check the FT AML console (Alert Manager, or Name Screening) to see the same result reflected on the platform side.

Platform & Architecture

The FT AML Platform is built as a high-throughput, multi-tenant SaaS architecture designed for real-time customer name screening, bulk dataset ingestion, transaction monitoring, and case management.

Architectural Overview

Scalability & Availability

• Fully managed SaaS infrastructure with continuous automated failover across availability zones.
• Isolated client tenant routing ensuring data privacy and zero cross-tenant contamination.
• Asynchronous event-driven webhook callbacks for instant alert notifications.

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://<bucket>/<client-id>/

Step 3 — Confirm API reachability

Objective: Verify network reachability to active API endpoints over HTTPS.

Submit a test JSON payload to the active Screening API endpoint:

{
  "request": "POST /riskradar/core/api/v1/screen",
  "headers": {
    "Content-Type": "application/json"
  },
  "body": {
    "customer_name": "Test User"
  }
}

Equivalent curl verification:

curl -i -X POST https://<host>/riskradar/core/api/v1/screen \
  -H "Content-Type: application/json" \
  -d '{"customer_name": "Test User"}'

Expected output: An HTTP 200 response with a JSON envelope containing code and data.

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.

Database Configuration

Database requirements, custom watchlist database integration, schema standards, and data persistence specifications for FT AML integrations.

Database Architecture & Indexing

FT AML manages underlying data persistence automatically. For clients bringing custom watchlist databases or maintaining local data stores, adhere to the following guidelines:

• Custom Watchlists — Store watchlist records with unique identifiers and ISO-compliant country codes.
• UTF-8 Character Set — Mandatory UTF-8 encoding for full international character and multi-language name support.
• Indexing — Index customer_id, customer_name, and screening_id fields for fast local lookups.

Data Retention & Backups

Ingested customer records and historical screening results are persisted securely in compliant storage with automated encrypted daily backups and standard audit trail logging.

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://<bucket>/<client-id>/customer/customer_<timestamp>.csv

2. Where to upload Account data

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

s3://<bucket>/<client-id>/account/account_<timestamp>.csv

3. Where to upload Transaction data

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

s3://<bucket>/<client-id>/transaction/transaction_<timestamp>.csv

4. Where/how to upload Watchlist data

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

s3://<bucket>/<client-id>/watchlist/watchlist_<timestamp>.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.

Customer Ingestion API

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

Screening API

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 Access — For Customer Ingestion API, Screening API, and API callback integration. Token-passing details provided by Fyscaltech.
• AWS Access — S3 bucket access credentials provided by Fyscaltech for Bulk upload via S3.

Module-wise Integration Guide

Step-by-step integration specifications across the core functional modules of the FT AML Platform.

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. What isn't yet confirmed in this documentation is the exact delivery mechanism for that result back to your system — likely a webhook, but confirm the specifics with your Fyscaltech integration contact before building against it.

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

A webhook would only be relevant if you're using the Customer Ingestion API's name_screening_enabled flag to trigger screening as part of ingesting a customer record, rather than calling the Screening API directly. Whether delivery actually happens via webhook — versus some other mechanism — isn't confirmed yet; the pattern below is the expected shape, not a confirmed spec.

How it works (expected pattern, not yet confirmed)

• Unlike Bulk upload, a webhook endpoint would be hosted and owned by you, not Fyscaltech
• Fyscaltech would provide the request format and signature-verification guidelines once finalized

Errors, Limits & Best Practices

Error codes, handling strategies, and platform error responses.

Business Error Codes

Deployment Guide

Instructions for deploying, configuring, and promoting FT AML integrations from staging to production.

Pre-Deployment Checklist

• Confirm API keys and AWS S3 bucket credentials are generated for the target production environment.
• Ensure outbound HTTPS (443) firewall rules and IP whitelisting are active on client servers.
• Verify TLS 1.2+ certificate validation on all client API communication channels.
• Test end-to-end webhook delivery endpoints using valid public SSL certificates.

Promoting to Production

Once non-prod testing is complete, switch API base URLs to the production endpoint hostname provided during onboarding, update API keys, and run a single test record verification.

Testing & non-prod

Guidelines for testing integrations in Fyscaltech sandbox and non-production environments.

Non-Prod Sandbox Setup

Fyscaltech provides a dedicated non-production environment for integration development, test file uploads, and dry-run screening API calls.

• Test Credentials — Separate API keys and test S3 bucket paths issued during onboarding.
• Sample Data Verification — Upload test files (50–100 records) to confirm schema formatting before volume testing.
• Mock Screening Calls — Execute test requests against /screen using test customer names to verify match scoring.

Validation Checklist

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

• 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.
• Non-Production and Production environment separation confirmed with Fyscaltech.

Logging

Logging and request tracing specifications.

Request Tracing

Request tracing information and tracking header specifications will be provided/told by 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.

Troubleshooting & FAQ

Common issues

Frequently asked questions

Glossary

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

Developer Community

A space for developers integrating with FT AML to ask questions, share patterns, and hear from each other — not just from Fyscaltech directly.

Resources & Changelog

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

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.

Appendix

Reference material collected in one place: acronyms, configuration templates, and sample payloads — each cross-referenced back to its full documentation elsewhere in this guide rather than duplicated in full.

Acronyms

Glossary

The full term-by-term glossary lives in its own section — see Glossary for every field name and platform term used throughout this guide.

References & external links

• FT AML product page
• FT AML User Guide — the console/end-user reference, as distinct from this Developer Guide
• Fyscaltech integration team — see Support

Configuration templates

Copy-paste-ready header rows for Bulk upload — full column-level reference is under Bulk data ingestion (upload via S3).

Customer file header (52 columns):

CUSTOMER_ID,CUSTOMER_TYPE,CUSTOMER_NAME,STATUS_CODE,CUSTOMER_SEGMENT_CODE,CUSTOMER_SEGMENT_NAME,RISK_LEVEL,RISK_SCORE,KYC_LEVEL,KYC_LEVEL_DESCRIPTION,PEP_FLAG,SANCTIONS_STATUS,SOURCE_OF_FUNDS,KYC_AUTHORIZED_SIGNATORY_NAME,ONBOARDING_DATE,ONBOARDING_CHANNEL,STREET,CITY,PROVINCE_REGION,ADDRESS_COUNTRY,POSTAL_CODE,CITIZENSHIP_COUNTRY,RESIDENCE_OPERATION_COUNTRY,BIRTH_INCORPORATION_COUNTRY,CUSTOMER_CONTACT_NO,ACCOUNT_TYPE,ACCOUNT_OPEN_DATE,ACCOUNT_AGE_DAYS,EXPECTED_MONTHLY_SPEND,EXPECTED_MONTHLY_SPEND_CURRENCY,EXPECTED_TXN_FREQUENCY,PURPOSE_OF_ACCOUNT,FIRST_NAME,MIDDLE_NAME,LAST_NAME,GENDER,DATE_OF_BIRTH_OR_INCORPORATION,CUSTOMER_AGE,CUSTOMER_ALIASES,CUSTOMER_ID_NO,CUSTOMER_ID_TYPE,CUSTOMER_ID_EXPIRY_DATE,CUSTOMER_ID_ISSUE_DATE,CUSTOMER_ID_COUNTRY,DESIGNATION,EMPLOYER_NAME,DECLARED_INCOME,INCOME_CURRENCY,NATURE_OF_BUSINESS,COUNTRY_OF_OPERATIONS,CREATED_AT,UPDATED_AT

Account file header (13 columns):

ACCOUNT_NUMBER,CUSTOMER_ID,ACCOUNT_TYPE,ACCOUNT_NAME,ACCOUNT_CURRENCY_CODE,ACCOUNT_BANK_NAME,ACCOUNT_BANK_COUNTRY,ACCOUNT_STATUS,ACCOUNT_HOLDING_TYPE,SIGNATORY_CUSTOMER_ID,SIGNATORY_NAME,CREATED_AT,UPDATED_AT

Sample requests & responses

Customer Ingestion API — full reference at Customer Ingestion API:

POST /datahub/ingestion/v1/customer

  
Content-Type: application/json
  
{ "customer_id": "CUST-1001", "customer_name": "Jane Doe", "customer_type": "Individual" }

202 Accepted

  
{ "code": "00000", "message": "success" }

Screening API — full reference at Screening API:

POST /riskradar/core/api/v1/screen

  
Content-Type: application/json
  
{ "customer_name": "Jane Doe", "customer_type": "Individual" }

200 OK

  
{ "code": "00000", "message": "Success", "data": { "screening_result": { "alert_score": 87.5, "alert_category": "HIGH" } } }

Documentation standards used in this guide

• Confirmed technical detail is stated directly; anything not yet confirmed by the technical team is marked with a "Will be published soon" callout or a TODO — Information Required tag, rather than guessed at.
• Existing screenshots and diagrams from the original guide are preserved as-is; new diagrams use the same flow-box/flow-arrow visual pattern already established in Integration Workflows.
• Every numbered procedure includes an objective, the exact commands, expected output, and a validation step, consistent with Installation Guide.