These evaluation questions are designed to cut through the marketing fluff. Vendors often use terms like “AI-powered” loosely; these questions will force them to reveal whether they are truly building a “One Funnel” (precision) architecture or simply patching a “Two Funnel” (filtering) system.

The evaluation framework has been restructured to distinguish between universal “Funnel” mechanics (applicable to both worlds) and those features that primarily drive efficiency in Static Data (KYC/Customer) screening.

Part 1: Universal Design Considerations

These factors are critical regardless of whether you are screening a static client database or a live wire transfer. They address the fundamental “One Funnel vs. Two Funnel” architecture of the engine itself.

1. The Matching Engine Mathematics (The “Funnel” Type)

Whether screening a customer name or a payment string, the core algorithm dictates the baseline efficiency.

• Question: “Is the matching engine based on deterministic/probabilistic algorithms (e.g., Levenshtein, Jaro-Winkler) or Semantic AI (Vector/Neural Networks)?”
• Why it’s Universal: Both transaction and static screening suffer from basic fuzzy matching errors (e.g., over-flagging “Main Street”). A “One Funnel” (Semantic) engine reduces noise in both environments by understanding context and meaning rather than just character overlap.

2. Synonym & Variation Handling

• Question: “Does the system identify synonyms (e.g., Bill = William, Ltd = Limited) via a hardcoded dictionary or learned semantic associations?”
• Why it’s Universal: A terrorist or sanctioned entity can disguise their name in a payment instruction just as easily as they can in account opening documents. If the system relies on a manual dictionary (Two Funnel), you have to maintain that dictionary for both workflows.

3. Data Normalization & Cleaning (Pre-Computation)

• Question: “How does the system handle dirty or concatenated strings (e.g., ‘IBM_CORP_NY’ or ‘PaymentRef:Inv#1234’)?”
• Why it’s Universal:
  • In Static: Bad data entry exists in legacy systems.
  • In Transactions: SWIFT/ISO messages often cram names, addresses, and references into single free-text fields.
  • Note: The system must be able to parse and clean these strings before matching, or the “One Funnel” engine will fail.

4. Model Governance & Explainability

• Question: “Can you generate a report explaining why a specific variation was not flagged?”
• Why it’s Universal: Regulators (OFAC/OFSI) require validation for both systems. If you cannot explain why a wire transfer wasn’t stopped (False Negative), or why a customer wasn’t flagged, the regulatory penalty is the same.

---

Part 2: Static Data-Specific Considerations

These considerations rely on rich, structured data (Dates of Birth, Citizenship, full addresses). They are highly effective for “Two Funnel” reduction in Static Data screening but are less applicable or difficult to implement in Transaction Screening because payment messages are often ephemeral, unstructured, and lack these specific data fields.

1. Multi-Dimensional Scoring (The “Tie-Breaker”)

• The Capability: Weighting the match score based on non-name attributes. (e.g., “If Name matches 100% but Year of Birth is >10 years apart, reduce score by 50%”).
• Why it’s Static-Dominant:
  • Static Data: You almost always have the KYC data (DOB, Country of Citizenship) to compare against the sanctions list.
  • Transaction Screening: A standard SWIFT MT103 or ISO 20022 message often does not contain the Date of Birth or Citizenship of the beneficiary. Therefore, a scoring model capable of weighing these factors is useless for the vast majority of payments.

2. Entity-Based Whitelisting (“Golden Record” Suppression)

• The Capability: Permanently suppressing a match for a specific customer entity ID after a human reviews it (e.g., “Client ID 12345 is NOT the terrorist John Smith. Never flag him again.”).
• Why it’s Static-Dominant:
  • Static Data: You screen the same unique “Customer ID” periodically. Once cleared, the “Two Funnel” whitelist prevents re-alerting on that ID.
  • Transaction Screening: You are screening a string of text in a message, not a “Customer ID.” The text might change slightly (“J. Smith” vs “Mr. John Smith”). You cannot reliably “whitelist” a text string without risking that a bad actor might use that same string later.

3. Delta Screening (Trigger-Based Scanning)

• The Capability: Only screening records that have changed or when the sanctions list updates, rather than re-screening the whole database every day.
• Why it’s Static-Dominant:
  • Static Data: This is the primary efficiency driver for customer databases.
  • Transaction Screening: Every transaction is a “new” event. You cannot “Delta screen” a wire transfer; you must screen the whole message every time it occurs.

Summary of Differences

Feature	Importance in Static Screening	Importance in Transaction Screening
Semantic AI Engine	High (Reduces review volume)	High (Reduces stopped payments)
DOB/Nationality Weighting	Critical (Major false positive reducer)	Low (Data rarely exists in message)
Entity Whitelisting	Critical (prevents “Groundhog Day” reviews)	Low (Too risky to whitelist text strings)
Address Fuzzy Matching	High (Matches client address to sanctioned city)	Medium (Payment addresses are often unstructured