FT AML Platform
Developer Portal

Introduction

This Developer Portal is the integration reference for the FT AML Platform. It's written for three audiences: customers connecting their own core banking or onboarding systems to FT AML, partners building on top of the platform on a customer's behalf, and Fyscaltech implementation teams delivering a go-live. Wherever a detail depends on your specific deployment — credentials, exact payload schemas, rate limits — this guide says so explicitly rather than guessing, and points you to the Fyscaltech integration team who confirms it during onboarding.

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, monitor transactions, manage investigations, and comply with AML/CTF regulations. The Developer Portal covers the integration surface of that platform — getting your data in, and getting screening results and alerts back out — rather than the compliance-analyst console itself.

There are three ways data moves between your systems and FT AML

• Bulk CSV via S3 — for loading or refreshing large volumes of Customer, Customer Account, and Customer Transaction records.
• Customer Ingestion API — for pushing or updating individual customer records from your own systems as they change.
• Screening API — for screening a specific customer record on demand, by full name.

Who does what

Quick Start

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 sandbox access — where a sandbox/test environment applies to your chosen method, credentials and connection details are issued as part of onboarding (see Testing & Sandbox).
3. Upload a sample customer — load a small test file via Bulk CSV, or a single record via the Customer Ingestion API, to confirm your data format is accepted.
4. Call the Screening API — or trigger screening automatically via the Customer Ingestion API — to confirm a screening result comes back for your test customer.
5. Receive a webhook — if you're using the ingest-then-screen flow, confirm your endpoint receives and correctly verifies the delivered result.
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

FT AML sits alongside your core banking and customer-facing systems, receiving data through the integration methods in this portal and returning screening results, alerts, and case outcomes.

How the pieces fit together

Data enters through one of the ingestion methods, is screened and monitored inside the platform, and any resulting alerts flow into Case Management for investigation — with results delivered back to you either via the console, or via webhook if you're using the ingest-then-screen flow.

Platform objectives

• Detect suspicious financial transactions by continuously monitoring customer and transaction activity
• Support banks and financial institutions in complying with applicable AML and Counter-Terrorist Financing (CTF) regulations
• Assess and calculate customer risk based on configurable risk parameters and business rules
• Generate timely alerts for unusual or potentially suspicious activity requiring further investigation
• Enable compliance teams to efficiently investigate, manage, and resolve AML cases
• Minimize false positive alerts through intelligent rule design and optimized risk assessment

Core Concepts & Data Models

A few ideas come up across all three integration methods. Understanding these up front makes the rest of this portal easier to follow.

Data models

Five record types recur across ingestion, screening, and case management. The field lists below are indicative — the confirmed schema for each is provided by the Fyscaltech integration team during onboarding.

Glossary

Integration Methods

The three ways data moves between your systems and the FT AML Platform, in detail.

Which one should I use?

Bulk data ingestion (CSV via S3)

For loading or refreshing data in volume, the platform reads CSV files uploaded to a dedicated location on AWS S3. Fyscaltech provides this location as part of onboarding — you don't need to request or configure it yourself.

Uploading follows the standard aws s3 cp <local-file> s3://<bucket-path-provided-by-fyscaltech>/ pattern, or the same upload can be done through the AWS Dashboard by navigating to the provided bucket, if you'd rather not use the CLI.

Customer Ingestion API

Ingests or updates a single customer's information from your own system — the API equivalent of a bulk Customer Record upload, but for one record at a time and in near real time as your data changes.

• Use it to create a new customer record, or update an existing one
• Can optionally be used to trigger screening on that customer as part of the same call — see Webhooks & Events for how the result comes back

Screening API

Performs screening on a specific customer record on demand.

• Submit a customer's full name to check it against watchlists
• Returns a screening result you can use to decide whether to proceed with onboarding or flag the customer for manual review

Authentication

Access is set up individually for each of the three integration methods during onboarding with the Fyscaltech team, rather than a single shared credential:

• Bulk CSV via S3 — Fyscaltech provisions the S3 bucket location your files are uploaded to, along with the AWS access credentials needed to write to it.
• Customer Ingestion API & Screening API — credentials and connection details for both APIs are issued by the Fyscaltech integration team as part of setting up your organization.
• Webhook — if you use the Customer Ingestion API to trigger screening, Fyscaltech provides the request format and security guidelines your webhook endpoint should follow to verify that a delivery genuinely came from the platform.

Security best practices

• Never embed credentials — AWS keys or API credentials — in client-side code (mobile apps, browser JavaScript). Keep them on your backend only.
• Store credentials in a secrets manager, not in source control or a plain environment file committed to a repo.
• Use separate credentials per environment or service where possible, so access can be revoked and audited independently.
• If you suspect a credential has leaked, contact Fyscaltech immediately to have it rotated — see Support.

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 (Customer Ingestion API triggers screening)

Bulk CSV — batch (sits outside both flows)

Bulk CSV 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 is only relevant if you're using the Customer Ingestion API to trigger screening as part of ingesting a customer record. If you call the Screening API directly instead, you get the result back in that same response and don't need a webhook at all.

How it works

• Unlike the other integration methods, the webhook endpoint itself is hosted and owned by you, not Fyscaltech — you stand up an endpoint that can receive an incoming request
• Fyscaltech provides the request format your endpoint will receive, along with security guidelines for verifying that a delivery genuinely came from the platform
• Once configured, screening results triggered via the Customer Ingestion API are delivered to your endpoint as they complete, instead of you needing to poll for them

Event types

The event names below describe the kinds of platform activity a webhook integration is expected to cover. Exact payload structure for each is confirmed with the Fyscaltech integration team.

Setting one up

1. Stand up an endpoint on your side that can receive an HTTPS request.
2. Contact the Fyscaltech integration team (see Support) with your endpoint URL and to receive the request format and security/signature verification guidelines.
3. Implement verification on your endpoint per the guidelines provided, so you can trust that an incoming request genuinely came from the platform rather than a third party.

Errors, Limits & Best Practices

Both the Customer Ingestion API and Screening API return standard HTTP status codes to indicate success or failure. The exact error payload structure, business error codes, and any rate limits are confirmed with the Fyscaltech integration team as part of onboarding.

HTTP status codes you can generally expect

Business error codes

Business-level error codes (e.g. the AML001–AML005 range and beyond) sit alongside the HTTP status and identify the specific validation or business rule that failed. The confirmed code list and meanings are published here once the Customer Ingestion and Screening API specifications are finalized.

Bulk CSV uploads

For bulk ingestion, check the FT AML console under Data Ingestion to confirm a file was picked up and processed successfully, rather than relying on the S3 upload itself as confirmation — a successful upload to S3 means the file arrived, not that every row in it passed validation.

Best practices

General integration practices that apply across all three methods, worth building in from day one rather than retrofitting later:

• Idempotency — design record creation/update calls so retrying a request with the same input doesn't create a duplicate.
• Retry strategy & exponential backoff — retry on 429 and 5xx responses with increasing delay between attempts, rather than retrying immediately in a tight loop.
• Timeout handling — set a sensible client-side timeout, and treat a timeout as "unknown outcome" rather than "failed" — check status before retrying.
• Webhook retries — expect Fyscaltech to retry webhook delivery on failure; make your endpoint idempotent so a redelivered event doesn't double-process.
• Correlation IDs — pass through or log the X-Request-Id (or equivalent) from responses so a specific request can be traced when raising a support issue.
• Rate limiting — respect published limits once confirmed; back off rather than queuing requests faster than the platform can process them.
• Pagination — for any endpoint returning lists, page through results rather than assuming a single response contains everything.
• Versioning — pin to a specific API version once published, and review the changelog before upgrading.
• Logging — log request/response metadata (not full PII payloads) to support troubleshooting without creating a compliance data-handling risk of its own.
• Security — see Authentication for credential handling; treat webhook payloads as untrusted until signature-verified.

Testing & Sandbox

Whether a separate sandbox/test environment is available for the Customer Ingestion and Screening APIs, and what test data it ships with, is confirmed with the Fyscaltech integration team as part of onboarding. For bulk CSV ingestion, the same S3 location and console feedback (Data Ingestion job status) apply regardless of whether you're testing or in production, so start with a small file to confirm your CSV format is accepted before uploading your full population.

Go-live checklist

• CSV format confirmed against a small test file before uploading your full customer, account, or transaction population
• Customer Ingestion API and/or Screening API integration tested end-to-end, including error handling
• If using the ingest-then-screen flow, webhook endpoint built and signature verification implemented per the guidelines provided by Fyscaltech
• A point of contact established with the Fyscaltech integration team for onboarding support and future changes
• Best practices from Module 09 (idempotency, retries, logging) reviewed against your implementation

Troubleshooting & FAQ

Common issues

Frequently asked questions

Resources & Changelog

Downloadable and reference materials to speed up integration work. Items marked coming soon are on the roadmap and will appear here once published.

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 (sandbox/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.