Skip to main content

​
What is AML Screening?

Anti-Money Laundering (AML) screening is a critical compliance process for identifying individuals and organizations with connections to financial crime. It involves checking customer data against global watchlists to detect risks related to money laundering, terrorism financing, sanctions violations, and political exposure. FrankieOne’s solution streamlines this process, from initial real-time screening at onboarding to continuous, automated monitoring throughout the customer lifecycle.

​
How AML Screening Works

Our AML capabilities are integrated directly into the FrankieOne workflow engine.
1

1. Create an Entity

First, you /create an organization entity with an organizationToken recorded from a lookup of the organization or you can use and entityId of an existing entity on which a data-fetch workflow like ownership or profile has been run using the /execute endpoint.
2

2. Execute a Workflow

You then execute a workflow that has been configured with an AML Step. Our platform takes the entity’s details and screens them against our connected data sources.
3

3. Receive Actionable Results

The workflow returns a clear result for the AML step—typically CLEAR or HIT. A HIT generates detailed Process Result Objects (PROs) and issues for any potential matches, allowing your team to investigate and classify the results.

​
What We Screen For

Our AML solution checks against a wide array of global sources to provide a comprehensive risk profile.
  • Politically Exposed Persons (PEPs): Identify individuals who hold prominent public functions and may present a higher risk for bribery or corruption.
  • Sanctions Lists: Screen against lists of individuals, entities, and countries subject to economic or trade sanctions by governments and international bodies.
  • Adverse Media: Scan global news sources for negative information linked to an individual that may indicate an elevated risk.
  • Other Regulatory & Law Enforcement Watchlists: Check against a wide range of official lists to identify potential bad actors.

​
Intelligent Matching

To increase accuracy and reduce false positives, our system uses sophisticated matching logic:
  • Name Matching: Checks against the entity’s full name, as well as known aliases.
  • Contextual Filtering: Uses the entity’s date of birth, nationality, and country of residence to filter out irrelevant matches from the screening results.

​
Classifying AML Hits

When an AML screening results in a HIT, your compliance team needs to review the potential matches and classify them. This is a critical step in managing your AML risk. You can update the status of one or more AML-related Process Result Objects (PROs) using the update /results/aml API. Request: 
PATCH /v2/organizations/{entityId}/results/aml
Request Body: 
{
  "processResults": [
    "pro_01J285FC7DH5G113KF109RJHSD",
    "pro_01J285FC6MDNE7SZPVS8D3GC7S"
  ],
  "manualStatus": "FALSE_POSITIVE",
  "comment": {
    "text": "Reviewed by compliance officer. Matches are for a different individual with a similar name."
  }
}

​
Manual Status Options (manualStatus)

When classifying a hit, you can set one of the following statuses:
StatusDescription
FALSE_POSITIVEThe match is not the same person you are onboarding.
TRUE_POSITIVEThe match is the same person, but a final decision has not been made. The hit remains unresolved.
TRUE_POSITIVE_ACCEPTThe match is the same person, and your organization has decided to accept the risk and proceed with the relationship.
TRUE_POSITIVE_REJECTThe match is the same person, and your organization has decided to reject the relationship.
UNKNOWNIt is unclear if the match is the same person. The hit remains unresolved.
UNKNOWN_ACCEPTIt is unclear if the match is the same person, but your organization has decided to accept the risk.
UNKNOWN_REJECTIt is unclear if the match is the same person, and your organization has decided to reject the relationship.
After classifying hits, it is best practice to re-run the workflow. The AML step will re-evaluate the results based on your classifications. For example, a workflow that initially resulted in a REVIEW status due to unresolved hits may change to PASS if all hits are classified as FALSE_POSITIVE.

​
Additional Resources