Operation & Source Workflow Logic

This page explains how Tom Custos workflow logic is structured for the public AML wiki, the main website and implementation planning.

1. Product sentence #

Tom Custos is configured for each client as a local AML operations agent: it follows the client’s checklist, uses selected source workflows, captures reproducible evidence, writes selected outputs and escalates uncertain or risky cases to the MLRO / compliance team for final decision.

Tom Custos is not:

• a sanctions database;
• a bundled AML data subscription;
• a cloud AML SaaS product;
• legal advice;
• a replacement for the MLRO / Head of Compliance.

2. Core distinction #

Operation workflow = what Tom does for the compliance team.
Source workflow    = where Tom checks while performing that operation.

Example:

Operation workflow:
  Client onboarding review

Source workflows inside it:
  Official sanctions databases
  Commercial AML databases
  PEP / RCA / SOE sources
  Company registries
  Domain and IP intelligence

Connectors and outputs:
  Google Sheets input
  PDF evidence export
  Google Sheets output
  MLRO escalation summary

3. Taxonomy used by Tom Custos #

4. Current operation workflow groups #

Tom Custos operation workflows describe what the local node does as AML work:

• Client onboarding review;
• Counterparty screening;
• Supplier review;
• Employee screening;
• Bank counterparty screening;
• Periodic client review;
• Pre-approval review;
• Priority chat check;
• EDD review & MLRO escalation support;
• Draft regulator response;
• Client document request.

5. Current source workflow groups #

Source workflows describe where Tom checks while doing the operation. The current grouped source logic is:

6. Paid-source boundary #

Commercial AML databases and specialist intelligence tools are connected only through the client’s existing subscription or approved access.

Do not imply that Tom Custos includes:

• LSEG World-Check;
• Dow Jones Risk & Compliance;
• LexisNexis / WorldCompliance;
• Moody’s GRID;
• Orbis / D&B / Sayari;
• Chainalysis / TRM / Elliptic-style tools;
• DomainTools or similar paid infrastructure intelligence;
• OpenSanctions as a free/open business source bundle.

OpenSanctions may appear in public discussion as an important sanctions / PEP / watchlist data project, but in Tom Custos commercial configurator logic it belongs under Commercial AML databases unless a specific client scope says otherwise.

7. How one operation uses many sources #

A counterparty screening operation may use:

1. Official sanctions databases.
2. Commercial AML database if the client has valid access.
3. Public search engines.
4. Company registries.
5. UBO / ownership intelligence.
6. Domain and IP intelligence.
7. Debarment or enforcement registers.

The operation is one business task. Each source category may still require its own source workflow, browser logic, evidence capture rules and error handling.

8. How one source can serve many operations #

A source workflow can be reused across multiple operations.

For example, a commercial AML database workflow may be used in:

• client onboarding;
• counterparty screening;
• supplier review;
• employee screening;
• periodic review;
• priority chat checks.

The source workflow can be reused, but every operation still needs its own input fields, source order, output format, evidence requirements and escalation logic.

9. Full AML operation lifecycle #

A complete Tom Custos cycle should preserve the same evidence-first structure:

10. Minimal individual check #

Example: “John Smith”.

Input:
  Name, optional date of birth, nationality, country, Case ID

Operation:
  Basic CDD / sanctions screening

Source workflows:
  Official sanctions databases
  Public search engines if configured
  Commercial AML database only if the client has valid access

Output:
  Evidence folder
  Structured table row
  Short team summary if configured
  MLRO escalation summary if risk/uncertainty exists

11. Minimal company check #

Example: “ABC Trading Ltd”.

Input:
  Company name, registration number if available, jurisdiction, website/domain, Case ID

Operation:
  Basic KYB / counterparty screening

Source workflows:
  Official sanctions databases
  Company registries
  Public search engines if configured
  Domain and IP intelligence if website/domain is available
  Commercial AML database only if the client has valid access

Output:
  KYB evidence pack
  company risk summary
  mismatch/red flag list
  MLRO handover if required

12. How this wiki should use the taxonomy #

This wiki is the public knowledge layer. It should explain universal AML logic:

• AML workflows;
• red flags;
• evidence collection;
• MLRO escalation;
• CDD / EDD;
• UBO;
• sanctions / TFS / CPF;
• adverse media;
• crypto AML;
• TBML;
• geographic exposure;
• digital jurisdiction exposure.

It should not be confused with paid source access. The wiki explains how checks work; the commercial Tom Custos implementation configures which operation workflows, source workflows, connectors, channels, evidence rules, nodes and implementation profile the client needs.

13. Shared verification and evidence control layer #

Every operation workflow should call the shared verification and evidence control layer before producing an output.

operation workflow
→ subject classification
→ declared-data inventory
→ approved source plan
→ source check records
→ evidence capture
→ discrepancy register
→ risk trigger mapping
→ review-ready output
→ audit trail

This prevents operation workflows from becoming generic narrative summaries. The agent must document what was declared, what was independently checked, what source limitations existed, which evidence supports the finding and what still needs analyst review.

Related pages:

• Verification & Evidence Control Layer
• Operation Workflow Patterns
• Case File & Evidence Lifecycle
• Discrepancy, Risk & Escalation Controls