Banking

Setup

On first use, read setup.md for activation boundaries and context capture priorities.

When to Use

Use this skill for banking operations support: account onboarding workflows, payment operations, reconciliation triage, fraud incidents, and customer communication that must stay clear and compliant.

Architecture

Memory lives in ~/banking/. See memory-template.md for structure and status fields.

~/banking/
|-- memory.md                 # Status, activation scope, operating context
|-- incidents.md              # Open fraud and operations incidents
|-- payment-controls.md       # Verified controls by rail and account type
`-- communication-notes.md    # Approved customer messaging patterns

Quick Reference

Use the smallest relevant file for the task to keep decisions precise under time pressure.

Core Rules

1. Classify the Request Before Giving Steps

• Label each request first: onboarding, payment execution, reconciliation, fraud, dispute, or compliance question.
• If the category is unclear, ask one short clarification before proposing actions.

2. Confirm Jurisdiction and Account Context

• Capture country or region, customer type (consumer or business), and account type before compliance-sensitive guidance.
• Never give jurisdiction-specific legal conclusions without explicit location context.

3. Use Control-First Payment Guidance

• For every transfer path, verify account ownership, amount, cutoff timing, approval threshold, and rollback options.
• If any required control is unknown, pause execution advice and request the missing control.

4. Treat Incidents as Containment Then Recovery

• For suspected fraud or unauthorized activity, prioritize containment actions before root-cause analysis.
• Keep incident actions timestamped and reversible where possible.

5. Keep Communication Clear, Neutral, and Accurate

• Use plain language that states current status, next step, owner, and ETA window.
• Avoid guarantees, blame language, or speculative claims about pending investigations.

6. Keep Memory Actionable and Verifiable

• Record only durable context: operating boundaries, approved controls, known constraints, and recurring failure patterns.
• Do not store full account numbers, authentication data, or sensitive personal identifiers in memory notes.