The AFC Ecosystem: How 30+ Institutions Share Financial Crime Intelligence Without Sharing Data

Financial crime does not stay within a single institution. A mule account network operates across multiple banks simultaneously. A fraud ring moves funds through accounts at three institutions before the pattern becomes visible at any one of them. A new laundering typology appears at a digital bank in Singapore before it shows up at a traditional bank in Malaysia.

Every institution that defends itself only from its own transaction history is working from an incomplete picture. The typologies it can detect are the ones it has already seen. The patterns that span multiple institutions are invisible in any single dataset.

The Anti Financial Crime (AFC) Ecosystem is Tookitaki's answer to this problem. It is a controlled repository of expert-validated financial crime scenarios and typologies, built and continuously updated by a community of financial institutions and financial crime experts. Institutions that connect to it access intelligence from a network of more than 30 banks and fintechs across APAC and beyond without any institution sharing customer data with another.

This guide explains how the AFC Ecosystem works, what the pipeline from community intelligence to institution-specific detection looks like, and what stays private throughout.

Why individual institution data has a ceiling

An AML model trained on a single institution's data learns from that institution's confirmed alerts, customer base, and transaction patterns. It becomes effective at detecting financial crime that looks like the financial crime that institution has already seen and reported.

The ceiling is structural. A typology that no customer at that institution has ever attempted will not appear in the training data. A coordinated attack that spreads transactions across four institutions generates suspicious patterns that are below threshold at each one individually, because each institution sees only its slice of the activity.

This is how financial crime networks exploit the siloed nature of institutional compliance. They move at the network level; most AML systems defend at the institution level.

The response to this gap is typically one of two approaches: regulatory intelligence sharing (slow and standardised) or commercial threat intelligence feeds (often backward-looking and delayed). Neither provides the calibration granularity needed to activate a typology against a specific institution's own transaction patterns.

What the AFC Ecosystem is

The AFC Ecosystem is a governed repository of financial crime scenarios, each validated by financial crime experts before it enters the library. The repository currently holds more than 380 typologies covering financial crime patterns across global markets, with a particular concentration in APAC.

The community that contributes to and draws from the repository includes financial institutions, regulators, and financial crime specialists. When a new pattern is identified at any institution in the network, it goes through an expert validation process before becoming a scenario in the library. The institution where the pattern was identified does not share customer records, transaction data, or account information. What enters the library is the behavioural logic of the typology: the pattern of customer, transaction, counterparty, and network behaviour associated with that type of financial crime.

This distinction is the foundation of the architecture. Customer data stays with the institution where it was generated. Typology intelligence, in the form of validated behavioural patterns, moves through the ecosystem.

From community intelligence to institution-specific detection: the five-stage pipeline

A typology in the AFC Ecosystem library does not automatically become a live detection control at an institution. It goes through a five-stage pipeline that translates community intelligence into a configuration calibrated for the institution's own data.

Stage 1: Identification and validation. A financial crime pattern is identified, validated by financial crime experts, and structured as a scenario in the AFC Ecosystem. This validation step ensures that what enters the library represents real financial crime behaviour, not a hypothesis or an uncorroborated single-institution finding.

Stage 2: AI translation. The validated scenario is translated into machine-readable behavioural risk factors using machine learning and natural language generation. This step converts the expert-defined typology into the structured indicators that the detection engine can act on, without requiring a compliance officer or data scientist to manually re-code the logic. This ability to move validated typologies from intelligence to deployable controls is a defining characteristic of an AI-native AML architecture.

Stage 3: Institution-specific calibration. An unsupervised model uses the institution's own historical data, approximately one year, to calculate the baseline and thresholds that reflect that institution's normal transaction patterns. The calibrated thresholds are specific to the institution. A threshold calculated for a major retail bank processing millions of low-value transactions will differ from a threshold calculated for a corporate treasury institution handling large-value payments, even if both connect to the same typology.

Stage 4: Simulation before go-live. The proposed configuration is tested through FinCense's Simulation Engine against the institution's historical transactions. Compliance teams can examine projected alert volumes, detection coverage, and precision before the configuration moves into production. A typology that generates an unworkable alert volume can be adjusted before it reaches the live detection queue.

Stage 5: Promotion, monitoring, and refinement. Validated controls are promoted to production and monitored continuously. Risk scores are aggregated and alerts are classified as high, medium, or low priority. The configuration can be adjusted as the institution's transaction patterns change.

The result of this pipeline is that a newly validated typology in the AFC Ecosystem library becomes a tested, deployable detection control at a connected institution in days rather than the weeks or months it would take to translate a typology into code manually.

What stays private

The privacy architecture of the AFC Ecosystem is worth stating precisely, because the value proposition depends on it.

Customer data, transaction records, account information, and personally identifiable information never leave the institution where they were generated. The AFC Ecosystem does not receive this data, does not store it, and does not transmit it between institutions.

What the ecosystem holds is typology logic: validated descriptions of financial crime behaviour expressed as structured patterns of customer, transaction, counterparty, and network attributes. No individual customer or transaction is identifiable from a typology description.

When an institution connects to the ecosystem and a typology is calibrated to their data in Stage 3, that calibration runs locally on the institution's own data. The calibrated thresholds reflect the institution's specific baseline and are retained within the institution's FinCense deployment. The ecosystem does not receive the calibration outputs.

This architecture means that collective intelligence strengthens each institution's detection capability without creating a central repository of financial data that spans multiple institutions. The network benefits from the pattern; each institution retains full control of its data, its thresholds, its risk appetite, and every validation and production decision.

Control stays with compliance teams, not IT

When an institution connects to the AFC Ecosystem and activates a typology from the library, the configuration process runs through Scenario Design Studio, a no-code interface for compliance and risk teams.

Segment thresholds, risk rules, match sensitivity, and model activation are controlled directly by the business, without an IT change request or vendor involvement. When a compliance team wants to activate a new typology, adjust a threshold following an examiner finding, or deactivate a scenario that is generating low-quality alerts, they make that change through the same interface.

Simulation runs before any change goes live. Every change is versioned and retained in the audit trail. This means a compliance team can respond to a regulatory development, an emerging threat, or an internal finding within hours rather than waiting for an engineering sprint.

The detection outcome

With the AFC Ecosystem active, FinCense reduces alert noise by 80 per cent or more. The improvement comes from two sources: better-calibrated thresholds that reflect the institution's actual transaction patterns, and access to validated typologies that the institution would not have been able to develop from its own data alone.

The second source is the more significant over time. Typologies that have been validated against real financial crime activity at multiple institutions perform better in production than typologies derived from a single institution's historical data, because they represent patterns that have actually been observed and confirmed rather than patterns that statistical analysis suggests might be suspicious.

For institutions that joined the network when the AFC Ecosystem was established, the typology library they now access reflects years of collective validation. New members access that accumulated intelligence immediately on connection, rather than building a typology library from scratch.

How the AFC Ecosystem connects to FinCense

The AFC Ecosystem is not a standalone product. It is the typology and intelligence layer that feeds FinCense's transaction monitoring, fraud detection, screening, and customer risk scoring modules. When a typology is activated from the library, it enters FinCense's three-stage transaction monitoring process: the typology is translated into behavioural risk factors in Stage 1, calibrated thresholds are generated through Automated Threshold Tuning in Stage 2, and alerts are risk-scored and prioritised in Stage 3. For a full explanation of that process, see our guide to how machine learning works in AML transaction monitoring.

For APAC fintechs navigating multi-regulator environments, the AFC Ecosystem's coverage of typologies across MAS, BNM, and BSP jurisdictions provides a starting point that would otherwise require significant manual research to build. For more on fintech-specific compliance obligations across APAC, see our guide to sanctions screening for fintechs in APAC.

To see how FinCense and the AFC Ecosystem work together for your institution, book a demo with our team.

Frequently asked questions

What is the AFC Ecosystem?

The Anti Financial Crime (AFC) Ecosystem is a controlled repository of expert-validated financial crime typologies and scenarios, maintained by a community of more than 30 financial institutions and financial crime experts across APAC and beyond. Institutions that connect to it access typology intelligence from the collective network without any institution sharing customer data with another. The repository currently holds more than 380 typologies across global markets.

Does the AFC Ecosystem involve sharing customer data between banks?

No. Customer data, transaction records, and personally identifiable information never leave the institution where they were generated. What moves through the ecosystem is typology logic: validated descriptions of financial crime behaviour expressed as behavioural patterns. When a typology is calibrated to an institution's data, that calibration runs locally on the institution's own data. The ecosystem does not receive or store customer records from any institution.

How does a typology in the AFC Ecosystem become a live detection control?

Through a five-stage pipeline: the typology is validated by financial crime experts, translated into machine-readable behavioural risk factors using AI, calibrated to the institution's own data via an unsupervised model, simulated against historical transactions before go-live, and then promoted to production where it is continuously monitored and refined.

How many typologies does the AFC Ecosystem contain?

The AFC Ecosystem library currently holds more than 380 typologies covering financial crime patterns across global markets, with strong coverage of APAC jurisdictions including Singapore, Malaysia, the Philippines, Australia, and New Zealand.

How long does it take to activate a new typology from the AFC Ecosystem?

A validated typology can become a tested, deployable detection control within days. The AI translation step replaces the manual re-coding that would otherwise take weeks. The Simulation Engine lets compliance teams validate projected alert volumes and detection precision before the control goes live, eliminating the need for a pilot period.

Who controls the typologies and thresholds at each institution?

Compliance and risk teams at each institution control their own scenarios, thresholds, match sensitivity, and model activation through Scenario Design Studio, without IT involvement. Each institution sets its own risk appetite and decides which typologies from the AFC Ecosystem library to activate. Every configuration change is simulated before production and retained in a versioned audit trail.