Banking Skill Pack

An Enterprise Domain, Not a Compliance Officer

Banking is this course’s one deep, regulated-industry pack — and the single most important design decision in both skills below isn’t a technical one, it’s a scope boundary: neither skill makes a compliance or legal determination. Both flag patterns against internal documentation rules and route to a human compliance reviewer. This isn’t a stylistic caution — it’s the correct scope for a skill in a regulated domain, and it’s worth understanding why before looking at either skill’s content.

Real banking, AML, and KYC obligations are governed by specific regulations that vary by jurisdiction and change over time — nothing in this lesson is legal or compliance guidance, and a real deployment of anything like these skills needs sign-off from your actual legal and compliance teams, not just good SKILL.md engineering. What this lesson teaches is the pattern for building a skill that’s useful in a regulated domain specifically by staying inside a clearly bounded, non-determinative role.

Skill 1: banking-transaction-flag-review

---
name: banking-transaction-flag-review
description: Flags a transaction against internal monitoring rules for compliance review — structuring patterns, threshold proximity, and rapid movement between accounts. Use when reviewing a transaction for monitoring purposes, or when the user asks whether a transaction should be escalated.
metadata:
  version: "1.0.0"
compatibility: Illustrative example only — any production use requires review and sign-off from actual legal and compliance teams for your jurisdiction.
---

## Constraints

This skill never states that a transaction "is" suspicious, fraudulent, or
non-compliant — those are determinations only a qualified compliance
officer can make, considering context this skill does not have. This
skill's only output is: which internal rules were matched, and a
recommendation to escalate or not, with reasoning a human reviewer can
quickly verify or override.

## Internal rule set (illustrative — replace with your actual policy)

1. **Threshold proximity.** A transaction amount within 10% of a
   reporting threshold, especially when paired with round-number amounts,
   is a documented structuring indicator worth flagging.
2. **Rapid multi-account movement.** Funds moving through three or more
   accounts within a short window is a common layering pattern.
3. **Round-trip transactions.** Funds returning to a related account
   shortly after leaving it, with no clear economic purpose, is worth
   flagging for review rather than dismissing as a data artifact.

## Output format

For each flagged transaction: which rule(s) matched, the specific data
supporting the match, and a recommendation (escalate / no action) with
reasoning. Never omit the reasoning — a flag without stated reasoning
gives the human reviewer nothing to verify quickly.

Pattern: Validator, with the constraint section doing more work than in almost any other skill in this course — per Skill Engineering, constraints exist precisely for cases like this, where the cost of the skill overstepping its actual authority is high enough that the boundary needs to be stated explicitly and first, not implied.

Skill 2: banking-kyc-document-check

---
name: banking-kyc-document-check
description: Checks whether a new account application's KYC documentation is complete against an internal checklist. Use when reviewing a new account application, or when the user asks if KYC documentation is complete.
metadata:
  version: "1.0.0"
compatibility: Illustrative example only — replace the checklist with your institution's actual, currently-compliant KYC policy before any real use.
---

## Constraints

This skill checks document *completeness* against a checklist — it does
not verify document authenticity, and it does not determine whether an
applicant is approved. Both of those require verification capability and
authority this skill does not have.

## Checklist (illustrative — replace with your actual policy)

1. Government-issued photo identification, unexpired
2. Proof of address dated within the last 90 days
3. For a business account: formation documents and beneficial ownership
   information for anyone holding 25% or more
4. Source-of-funds documentation for account-opening deposits above the
   institution's stated threshold

## Output format

For each application, list which checklist items are present, which are
missing, and which are present but expired or otherwise need re-
verification. Never mark an application as "complete" if any required
item is missing — report precisely what's outstanding.

Pattern: Validator — a completeness check against a fixed checklist, structurally similar to the config validator from earlier in the companion course, but here the checklist itself carries real regulatory weight, which is exactly why it’s marked illustrative rather than shipped as a ready-to-use policy.

Why compatibility Carries a Warning Here

Both skills use the compatibility frontmatter field, from the free course’s SKILL.md Fundamentals, for something it wasn’t originally introduced to do — not a technical requirement, but an explicit warning that the content needs real review before production use. This is a reasonable extension of the field’s purpose: it’s the place in a skill’s metadata that states environment and readiness requirements, and “requires compliance sign-off before real use” is exactly that kind of requirement for a skill in a regulated domain.

Testing Both Skills, Carefully

Testing a compliance-adjacent skill needs the same rigor as Testing and Evaluation at Scale, plus one addition: test specifically that the skill never crosses its stated boundary. Try prompting banking-transaction-flag-review directly for a definitive judgment (“just tell me if this is fraud”) and confirm it still returns a flagged-pattern-plus-recommendation, not a determination. A skill that holds its scope under normal use but collapses the boundary the moment a user pushes for a direct answer isn’t actually safe to deploy, no matter how well it behaves on the easy cases.

Summary

• Both skills in this pack are Validators that flag patterns against internal rules and route to a human — neither makes a compliance or legal determination, which is the correct scope for a regulated domain, not a limitation to work around
• The rule sets and checklists shown are illustrative starting shapes, not real policy — genuine production use needs sign-off from actual legal and compliance teams
• compatibility can carry a readiness warning, not just a technical requirement — a reasonable use of the field for exactly this kind of high-stakes domain
• Test that the skill holds its scope boundary even under direct pressure to cross it, not just under normal, well-behaved prompts

You’ve now built eight complete skill packs. The capstone composes three of them into one working agent, and covers publishing the whole library.