Prompt Scenarios: Banking & Payments

Every scenario below was run against the live platform while writing this page. Where a screening example needed a real hit to be worth showing, it uses a name that is itself the point of a compliance check — a long-designated bank or a sitting public office holder, both matters of public record. Counterparty names used only to illustrate a form field are fictional.

---

1. Who This Is For

Banks, PSPs, EMIs, and anyone running KYC/KYB onboarding or payment screening — over the in-cabinet AI Assistant or an external ChatGPT/Claude client connected via MCP. After connecting, there are no slash commands: the model chooses a tool from the wording of the request.

• ChatGPT. chatgpt.com → Connectors → add the Compliance MCP server.
• Claude. claude.ai → Settings → Connectors → Add MCP server.

---

2. Individual KYC Before Account Opening

Prompt: "Check whether Igor Sergeyevich Orlov (DOB 1968-11-02, Russian citizen) is on EU, OFAC, UN or UK sanctions lists."

Tool: screen_entities — query, date_of_birth, country="RU", entity_type="natural_person".

What you get back: a score 0–100 per match, source list, regulation, grounds, and a full score explanation — which signal won (exact identifier, exact token, phonetic, or edit distance), whether the DOB or country bonus applied, and whether a safety cap held the score down. See Entity Screening Algorithms for how that score is actually assigned.

---

3. Company Counterparty Screening

Prompt: "Which sanctions lists include Sberbank? Show the matches with regulations."

Tool: screen_entities — query="Sberbank", entity_type="legal_person".

Verified live: this returns real matches — PUBLIC JOINT STOCK COMPANY SBERBANK OF RUSSIA and several subsidiaries (Sberbank Capital, Sberbank Leasing, Sberbank Europe AG, BPS-Sberbank), all at score 100 via OFAC_SDN under the UKRAINE-EO13662 program, each one linked back to the parent entity in its grounds text. A single-word legal-person query like this returns everything sharing that exact token — raise limit past the default 10 if you expect a large corporate family and want to see all of it, not just the highest-scoring handful.

---

4. Screening By Registration Number

Prompt: "Screen company registration number 40003151743 and tell me whether the identifier gives an exact match."

Tool: screen_entities with registration_number.

An exact identifier match forces final_score = 100 regardless of how the name compares — identifier evidence is stronger than name evidence, and the response marks document_match: true so this is explainable as identifier evidence, not a fuzzy name coincidence.

---

5. Point-In-Time / Audit Screening

Prompt: "As of 2025-01-01, was this company active on sanctions lists? Include closed historical records."

Tool: screen_entities with as_of_date and include_historical_closed=true.

Reconstructs the sanctions-list state as it stood on that date using SCD2 history, and states whether each match was active or already delisted on that date — the tool this content applies to is /audit in the cabinet, which (unlike /entity) also accepts an Address field as a separate matching signal.

---

6. Verification Of Payee

Prompt: "For payment verification, compare payee name 'Sberbank' against sanctions records using VoP close-match logic."

Tool: screen_entity_vop.

Verified live, and worth knowing before you rely on it: this actually returned NMTC — no match — even though the identical query scores 100 in ordinary screen_entities. VoP is a different, stricter algorithm: it classifies how closely a specific payee name string matches a specific registered name, under EPC288-23 scenario rules (exact, s2a_levenshtein, s2b_transposition, s2c_initial, s2d_phonetic). "Sberbank" against the full registered name "Public Joint Stock Company Sberbank of Russia" doesn't clear that bar. The two tools answer different questions and can legitimately disagree — VoP is not a shortcut for sanctions screening, and a VoP no-match is not evidence of a clean counterparty.

---

7. Politically Exposed Person Check

Prompt: "Is Jean-Claude Juncker a politically exposed person? I need to decide whether enhanced due diligence applies."

Tool: screen_pep.

Verified live: a real match — pep_status: active, pep_class: national, office "Deputy of the Chamber of Deputies of Luxembourg" (his current position, not his former one as European Commission President — the layer tracks the active office, honoring the FATF/AMLD 12-month grace period after someone leaves a post before downgrading them to former). Source: Wikidata, with a direct source URL for the record.

A PEP hit is a risk signal, not a block. It recommends Enhanced Due Diligence, not refusal. Run screen_pep alongside screen_entities, not instead of it — a person can be both a PEP (EDD) and separately sanctioned (block), and these are two different questions.

Current coverage: EU-27 and European Parliament office holders, plus Georgia's ACB asset-declaration data, the Latvian Saeima, the Estonian Riigikogu, the Lithuanian Seimas, and a Central Asia parliamentary layer (Kazakhstan, Kyrgyzstan, Uzbekistan) — and this keeps growing, so treat screen_pep's own result as the current word on coverage rather than this list.

---

8. KYB — Resolving A Company From A Registry

Prompt: "Look up SEB banka in the Latvian company register and show its registration details."

Tool: search_business_registry — query, country="LV".

This is not covered in the older prompt-scenario reference at all — it's genuinely new capability. Verified live: a real result — AS "SEB banka", registry code 40003151743, registered 1993-09-28, status active, plus a list of formerly-registered branches now shown as terminated. Covers Latvia, Estonia, Kazakhstan and Poland (Polish KRS currently only by exact KRS number).

Registry data is reference evidence, not a sanctions clearance. Follow up with get_business_registry_profile for the full company card and related-party records, or skip straight to the composite flow below.

---

9. KYB — Company Plus Beneficial Owners, In One Call

Prompt: "Resolve SEB banka in the Latvian registry, then screen the company and its officers and beneficial owners against sanctions."

Tool: screen_business_entity_with_related_parties.

A single call that resolves the registry company, pulls officers and UBOs from the official source, screens the company itself plus the selected related parties, and returns one aggregate decision. include_officers and include_beneficial_owners default on; include_shareholders defaults off since it's more profile-dependent. This is the fastest path from "here's a company name" to "here's who behind it might be a problem."

---

10. ISO 20022 — Validating A Payment Message

Prompt: "Here is a pain.001 XML. Validate the structure and extract the payment chain."

Tool: validate_iso20022_payment.

Verified live, and this is worth knowing before you build your own test messages: the XSD validation is strict. A message missing CreDtTm in GrpHdr, or missing CtrlSum/InitgPty, comes back xsd_validation_status: invalid with the exact schema complaint — but the parser still extracts the full participant chain regardless, so a structurally imperfect message still gives you something to work with, clearly labeled as an integrity_error rather than silently treated as clean.

Also verified: BIC resolution genuinely calls out to GLEIF. A message naming the sender bank as plain "Sberbank" against BIC SABRRUMMXXX resolves to the real registered legal name (Публичное акционерное общество "Сбербанк России") with a real LEI (549300WE6TAF5EEWQS81) and a working GLEIF source URL — and flags a bic_resolved_name_mismatch warning because the name in the XML didn't match what GLEIF returned. That mismatch warning is exactly the kind of thing that should hold a payment for review, not wave it through.

---

11. ISO 20022 — Screening Every Participant

Prompt: "Open the payment screening form, screen this pacs.008 message, then show the payment chain and explain who needs review."

Primary flow: open_payment_screening_form.

To make sure it saves into cases: paste the XML, enable Persist payment case, submit — the response should include a case_id. If the checkbox was off, don't resubmit the XML to ask a follow-up question; read the already-saved one-shot result with get_payment_screening_run (by run_id, or with no arguments at all for the latest active run in the session).

Follow-up questions that work without rerunning anything:

---

12. Agentic BIC Enrichment For Unresolved BICs

Prompt: "This message has BICs the local cache and GLEIF couldn't resolve. Prepare web-search tasks for them, but don't change the payment verdict."

Tool: resolve_payment_bics_agentic.

MCP-only, and deliberately not a compliance decision — it prepares web-search tasks for unresolved BICs and nothing else. Any value it surfaces must be marked UNVERIFIED (web search), and screen_entities is still required on the resulting name before the payment can be cleared on it.

---

13. What Not To Do

• Don't send more personal data than the check needs. Name, country, date of birth and a registration number cover almost every screening scenario.
• Don't treat a VoP no-match as a clean sanctions result, or a sanctions clear as a VoP match — §6 shows they can genuinely disagree on the same query.
• Don't resubmit XML to ask a follow-up question about a payment already screened — read the saved run instead.
• Don't clear a payment on agentic BIC-enrichment evidence alone — it's unverified web search, not a screening result.

---

14. Related Material

• Entity Screening Algorithms — how the score in every result above is actually calculated
• AI Assistant User Guide — the in-cabinet slash commands (/entity, /audit, /vop, /pep, /payment) behind these same tools