Use when reviewing an AML/BSA or equivalent anti-money-laundering compliance program document set against the program elements the firm's own policy or a user-supplied regulatory framework defines, to inventory the program documents, map each required element to where the program addresses it, build a gap matrix, and package verification items for compliance and attorney review.
When to use
A user says "gap-check our AML program," "map our BSA program against the pillars in our policy," or "review these program documents against this framework."
A firm is preparing for an examination, an independent test, or an internal audit and needs its program documentation organized against a defined element structure first.
A compliance officer needs a structured first-pass coverage map before deciding where to remediate.
A program document set has grown across versions and owners and needs a documentation-coverage baseline.
Required inputs
The program document set: the actual documents — uploaded or pasted. Typically the program policy, the AML/financial-crime risk assessment, CDD/KYC procedures, transaction-monitoring and screening procedures, training materials or records, independent testing or audit reports, and governance documents such as the compliance-officer designation. If no document set is provided, stop and request it.
The framework defining the required elements: the firm's own program policy where it defines the program's required elements, or a user-supplied regulatory framework document. If no framework is provided, stop and request it. Do not construct required program elements from model background knowledge — the element list must come from a provided document.
Jurisdiction and regime context: the jurisdiction(s) and regulatory regime the program operates under. If unknown, flag [verify jurisdiction] and state how the gap analysis is limited without it. The skill is jurisdiction-neutral; it applies whatever framework the user supplies and asserts nothing about the law of any jurisdiction.
Prior findings (optional): prior examination, audit, or independent-testing findings, so open findings can be cross-referenced to the gaps.
If the document set or the framework is missing, stop and request it. If the framework is provided but does not define required elements, say so and ask the user to identify the element source rather than inferring one.
Use when reviewing an enhanced-due-diligence file for a high-risk customer — a PEP, a high-risk-jurisdiction customer, a complex ownership structure, a cash-intensive business, or a correspondent relationship — to inventory the EDD file against the firm's EDD policy, organize source-of-wealth and source-of-funds documentation status, map the beneficial-ownership chain with its gaps, and package a draft escalation and disposition recommendation for the compliance officer.
When to use
A user says "review this EDD file," "check whether this PEP file meets our EDD policy," or "organize the source-of-wealth documentation for this high-risk client."
A customer has been escalated to enhanced due diligence — as a PEP, a high-risk-jurisdiction customer, a complex ownership structure, a cash-intensive business, or a correspondent relationship — and the assembled file needs a structured first-pass review before approval.
A periodic EDD refresh is due and the existing file must be checked against the firm's current EDD policy.
A kyc-onboarding-review run produced an escalate-to-EDD disposition and the resulting EDD file is now ready for review.
Required inputs
The EDD file: the actual documents — uploaded or pasted. Typically source-of-wealth and source-of-funds evidence, ownership and control documents (registers, org charts, trust deeds, UBO declarations), sanctions / PEP / adverse-media screening results, the documented purpose and intended nature of the relationship, any site-visit or reference reports, and senior-management approvals. If no file is provided, stop and request it.
The firm's EDD policy or procedures: the firm document defining which enhanced measures apply to which risk drivers, the documentation standards, and the approval requirements. If not provided, stop and request it. Do not construct EDD requirements from model background knowledge.
Customer context: the risk driver(s) that triggered EDD (as documented or user-stated) and the nature and purpose of the relationship.
Prior periodic reviews (optional): earlier EDD or periodic-review outcomes for the customer.
Transaction or expected-activity data (optional): where provided, it informs the consistency observations; the skill does not perform transaction monitoring.
If the EDD file or the EDD policy is missing, stop and request it. If the risk driver that triggered EDD is not stated anywhere, ask — the applicable policy requirements cannot be identified without it.
Use when reviewing a client or investor onboarding packet to inventory documents, extract KYC fields, apply the firm's KYC/AML rules grid, propose a customer risk rating, and assemble an escalation packet for compliance and attorney review.
When to use
A user says "run KYC on this new client," "review this onboarding packet," or "screen this investor for onboarding."
A new client or investor is being onboarded, or a periodic KYC refresh is due.
A firm needs a structured first-pass file before a compliance officer makes a customer-acceptance or risk-rating decision.
An onboarding analyst needs to organize identity, ownership, control, and source-of-funds information against the firm's rules grid.
Required inputs
Onboarding document packet: the actual documents — uploaded or pasted. This typically includes identity documents, entity formation documents, ownership and control documents (UBO declarations, org charts, registers, resolutions), address proof, source-of-funds or source-of-wealth evidence, and tax forms. If no packet is provided, stop and request it.
The firm's KYC/AML rules grid or CDD policy: the actual firm document setting out the due diligence rules, required documents by customer type and risk level, and the risk-rating methodology. If not provided, stop and request it. Do not construct rules or document requirements from model background knowledge.
High-risk jurisdiction list and risk-rating methodology (if maintained separately from the rules grid).
Screening results (optional): sanctions, PEP, and adverse-media results for each named party, if a screening run has been completed. The skill does not perform live screening; it organizes and reviews results that are provided. If no screening has been run, note that screening is pending.
Customer context: applicant type (individual, entity, trust) and the nature of the intended business relationship.
If the packet or the rules grid is missing, stop and request it. If documents are too incomplete to enable meaningful extraction, ask targeted follow-up questions.
Use when reviewing sanctions, PEP, or adverse-media screening results for named parties to compare identifiers, classify each potential match by confidence, separate likely false positives from genuine hits, and recommend a disposition for compliance and attorney review.
When to use
A user says "review these screening hits," "adjudicate these PEP matches," or "help me work through these sanctions alerts."
A screening run — at onboarding or as part of ongoing monitoring — has generated potential matches that need first-pass review.
A firm needs a structured comparison and confidence classification before a compliance officer dispositions alerts.
Required inputs
The screening results: the actual alert list or hit report — the screened name, the list source for each hit, the matched list entry, and the match score where one is given. If no screening results are provided, stop and request them.
Identifying data for the screened party: date of birth or formation date, nationality or jurisdiction, addresses, and any identifiers — so the screened party can be compared against the matched entry.
The firm's screening or alert-disposition policy: the firm document setting out match thresholds, false-positive criteria, and escalation rules. If not provided, stop and request it. Do not apply thresholds from model background knowledge.
Screening context: the lists screened against, the as-of date of the screening run, and whether this is onboarding or ongoing monitoring.
If the screening results or the disposition policy is missing, stop and request it.
Use when triaging a transaction-monitoring alert or small alert batch on an existing customer to inventory the alert and the rule that fired, compare the customer's expected-activity baseline against observed activity, structure the escalate / close / request-more-information analysis, and package a documentation-of-rationale draft for the compliance officer's disposition decision.
When to use
A user says "triage this transaction-monitoring alert," "work through these TM alerts," or "help me document this alert review."
A monitoring rule or scenario has fired on an existing customer and a first-pass, structured review is needed before the compliance officer dispositions the alert.
An analyst needs the customer's expected-activity baseline organized against observed activity so the disposition rationale can be documented.
A small batch of related alerts on the same customer needs to be organized into one coherent triage file.
Required inputs
The alert record(s): the actual alert data — the alert identifier, the monitoring rule or scenario that fired, its parameters or thresholds as stated in the alert or the firm's rule documentation, the review window, and the triggering transactions. If no alert record is provided, stop and request it.
The customer profile: the KYC file or a current extract — customer type, current risk rating, the expected-activity or anticipated-transaction baseline recorded at onboarding or last review, and the nature of the relationship. If no profile is provided, stop and request it; expected-versus-observed comparison is the core of the triage.
Transaction data for the review window: the triggering transactions and enough surrounding activity to give context, with dates, amounts, channels, and counterparties as recorded.
The firm's alert-triage or investigation procedure: the firm document setting out disposition options, escalation criteria, and documentation requirements. If not provided, stop and request it. Do not apply triage criteria from model background knowledge.
Prior alerts and dispositions (optional): the customer's alert history, if available.
Screening results (optional): sanctions, PEP, and adverse-media results for the customer and alert counterparties, if a run has been completed. The skill does not perform live screening.
If the alert record, the customer profile, or the triage procedure is missing, stop and request it before substantive work.