Banking Skill Pack

A new LangGraph course lesson, "Banking Skill Pack," teaches how to build two Validator skills for banking compliance — banking-transaction-flag-review and banking-kyc-document-check — that flag transactions and KYC documentation against internal rules for human review, explicitly never making final compliance or legal determinations. The lesson emphasizes that neither skill acts as a compliance officer, and any production use requires sign-off from actual legal and compliance teams.

· Agentic AI · 6 min read 📋 Prerequisites - LangGraph Skill Pack previous lesson 🎯 What You'll Learn - Build a Validator skill that flags transactions against internal monitoring rules for human review - Build a Validator skill that checks KYC documentation completeness for a new account - Design a compliance-adjacent skill that explicitly never makes the final regulatory determination itself 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 /courses/production-agent-skills-engineering/skill-engineering-fundamentals , 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 /courses/production-agent-skills-engineering/skill-quality-anti-patterns 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 /courses/agent-skills-mastery/skill-md-format-specification , 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 /courses/production-agent-skills-engineering/testing-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.