Profiles and domains

Tenant profile

Each FPP instance is deployed with a profile: fraud, aml or both. The profile is part of the tenant’s deployment configuration and is the same key read by the FPP and by the CMP of that tenant.

Profile	What the institution contracted	What appears
fraud	Fraud prevention	Fraud workbench, engine, lists, UBA, backtest
aml	Anti-money laundering	Scenarios, parametrization matrix, alert list, dispatch to the Desk
both	Both	Everything above, in the same panel

An absent profile counts as fraud. An instance that already operates fraud gains no AML surface by accident, and a tenant only gains AML when someone writes aml or both in the configuration.

What the profile governs, and what it does not

The profile governs the surface and the outbound emission:

• the AML menu items and routes in the FPP panel;
• the AML links and screens in the CMP;
• the dispatch of alerts to the Decision Desk, which only happens when the profile includes AML.

The profile does not govern evaluation. What decides whether a transaction is evaluated in a domain is the existence of an active workflow in that domain. This separation is deliberate: the same transaction sent to two instances with the same workflow receives the same decision, and no deployment configuration changes an engine result.

Domains and workflows

The engine has one active workflow per domain. A tenant with the both profile has a fraud workflow and an AML workflow, each with its own stages, policies, rules and thresholds, edited in the same visual editor.

When a transaction comes in, it comes in once and is evaluated once per active domain. With fraud and AML active, the fraud decision is returned in the call itself, within the contracted response time, and the AML evaluation runs right after, outside the call, without extending the fraud latency and without competing for resources with webhook delivery to the integrator.

An AML-only tenant evaluates normally: the AML workflow is the only active domain and it is the one that decides. The AML workflow is created through the API or through the editor, choosing the domain at creation, like any other workflow.

The speaking gate

The platform checks, at startup and periodically, whether there is an active workflow in any domain outside the tenant’s profile. When there is, it deactivates nothing: it records a stable warning and shows it on the administrator’s system screen. An active AML workflow in a tenant with the fraud profile keeps evaluating, because the workflow is the authority over evaluation, and the administrator sees the divergence in order to correct the configuration.

The same profile in the Decision Desk

The CMP of the same tenant reads the same profile. The AML screens and links in the Desk appear when the profile includes AML, and the Desk starts accepting the alerts dispatched by the FPP. The deployment configuration validates that the two modules of the same tenant declare the same profile.