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.
| Topic |
File |
| Setup process |
setup.md |
| Memory template |
memory-template.md |
| Request intake and classification |
intake-checklist.md |
| Payment rails and controls |
payment-ops.md |
| Fraud and outage handling |
incident-response.md |
| Customer-safe wording |
customer-messaging.md |
| Regulatory and legal boundaries |
compliance-scope.md |
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.
7. Escalate High-Risk or Restricted Requests
- Escalate when requests involve sanctions, KYC circumvention, legal interpretation, or irreversible fund movement without controls.
- Refuse instructions that circumvent required approvals, customer consent, or regulatory safeguards.
Common Traps
- Starting with product explanations instead of request classification -> slower resolution and wrong workflow.
- Giving transfer steps before confirming controls -> elevated operational and fraud risk.
- Mixing legal interpretation with operations guidance -> compliance exposure and user confusion.
- Responding to incidents with generic advice only -> delayed containment and larger losses.
- Using absolute language such as "guaranteed" or "always" -> credibility and regulatory risk.
- Logging sensitive data in memory notes -> avoidable privacy and security exposure.
Data Storage
- Local notes only in
~/banking/ (memory file, incident notes, and control references).
- Keep stored content minimal and operational: controls, status, and decisions.
- Do not store full account numbers, authentication data, or unnecessary personal identifiers.
Security & Privacy
Data that leaves your machine:
- None by default. This skill is instruction and workflow guidance only.
Data that stays local:
- Operational context and notes in
~/banking/.
This skill does NOT:
- Access bank portals or execute fund transfers automatically.
- Request undeclared network calls.
- Store authentication data or full account numbers in memory files.
- Modify files outside
~/banking/ for storage.
- NEVER modifies its own skill definition file.
Related Skills
Install with clawhub install <slug> if user confirms:
payments - Payment workflows and transaction operations patterns.
accounting - Ledger, reconciliation, and financial reporting support.
invoice - Invoice lifecycle workflows and settlement tracking.
money - Personal money management and budgeting fundamentals.
invest - Investment analysis workflows for portfolio decisions.
Feedback
- If useful:
clawhub star banking
- Stay updated:
clawhub sync
1---2name: banking3description: Manage retail and business banking workflows with payment operations, account controls, reconciliation, fraud response, and compliant communication.4---56## Setup78On first use, read `setup.md` for activation boundaries and context capture priorities.910## When to Use1112Use this skill for banking operations support: account onboarding workflows, payment operations, reconciliation triage, fraud incidents, and customer communication that must stay clear and compliant.1314## Architecture1516Memory lives in `~/banking/`. See `memory-template.md` for structure and status fields.1718```text19~/banking/20|-- memory.md # Status, activation scope, operating context21|-- incidents.md # Open fraud and operations incidents22|-- payment-controls.md # Verified controls by rail and account type23`-- communication-notes.md # Approved customer messaging patterns24```2526## Quick Reference2728Use the smallest relevant file for the task to keep decisions precise under time pressure.2930| Topic | File |31|-------|------|32| Setup process | `setup.md` |33| Memory template | `memory-template.md` |34| Request intake and classification | `intake-checklist.md` |35| Payment rails and controls | `payment-ops.md` |36| Fraud and outage handling | `incident-response.md` |37| Customer-safe wording | `customer-messaging.md` |38| Regulatory and legal boundaries | `compliance-scope.md` |3940## Core Rules4142### 1. Classify the Request Before Giving Steps43- Label each request first: onboarding, payment execution, reconciliation, fraud, dispute, or compliance question.44- If the category is unclear, ask one short clarification before proposing actions.4546### 2. Confirm Jurisdiction and Account Context47- Capture country or region, customer type (consumer or business), and account type before compliance-sensitive guidance.48- Never give jurisdiction-specific legal conclusions without explicit location context.4950### 3. Use Control-First Payment Guidance51- For every transfer path, verify account ownership, amount, cutoff timing, approval threshold, and rollback options.52- If any required control is unknown, pause execution advice and request the missing control.5354### 4. Treat Incidents as Containment Then Recovery55- For suspected fraud or unauthorized activity, prioritize containment actions before root-cause analysis.56- Keep incident actions timestamped and reversible where possible.5758### 5. Keep Communication Clear, Neutral, and Accurate59- Use plain language that states current status, next step, owner, and ETA window.60- Avoid guarantees, blame language, or speculative claims about pending investigations.6162### 6. Keep Memory Actionable and Verifiable63- Record only durable context: operating boundaries, approved controls, known constraints, and recurring failure patterns.64- Do not store full account numbers, authentication data, or sensitive personal identifiers in memory notes.6566### 7. Escalate High-Risk or Restricted Requests67- Escalate when requests involve sanctions, KYC circumvention, legal interpretation, or irreversible fund movement without controls.68- Refuse instructions that circumvent required approvals, customer consent, or regulatory safeguards.6970## Common Traps7172- Starting with product explanations instead of request classification -> slower resolution and wrong workflow.73- Giving transfer steps before confirming controls -> elevated operational and fraud risk.74- Mixing legal interpretation with operations guidance -> compliance exposure and user confusion.75- Responding to incidents with generic advice only -> delayed containment and larger losses.76- Using absolute language such as "guaranteed" or "always" -> credibility and regulatory risk.77- Logging sensitive data in memory notes -> avoidable privacy and security exposure.7879## Data Storage8081- Local notes only in `~/banking/` (memory file, incident notes, and control references).82- Keep stored content minimal and operational: controls, status, and decisions.83- Do not store full account numbers, authentication data, or unnecessary personal identifiers.8485## Security & Privacy8687Data that leaves your machine:88- None by default. This skill is instruction and workflow guidance only.8990Data that stays local:91- Operational context and notes in `~/banking/`.9293This skill does NOT:94- Access bank portals or execute fund transfers automatically.95- Request undeclared network calls.96- Store authentication data or full account numbers in memory files.97- Modify files outside `~/banking/` for storage.98- NEVER modifies its own skill definition file.99100## Related Skills101Install with `clawhub install <slug>` if user confirms:102- `payments` - Payment workflows and transaction operations patterns.103- `accounting` - Ledger, reconciliation, and financial reporting support.104- `invoice` - Invoice lifecycle workflows and settlement tracking.105- `money` - Personal money management and budgeting fundamentals.106- `invest` - Investment analysis workflows for portfolio decisions.107108## Feedback109110- If useful: `clawhub star banking`111- Stay updated: `clawhub sync`