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---5
6## Setup
7
8On first use, read `setup.md` for activation boundaries and context capture priorities.
9
10## When to Use
11
12Use this skill for banking operations support: account onboarding workflows, payment operations, reconciliation triage, fraud incidents, and customer communication that must stay clear and compliant.
13
14## Architecture
15
16Memory lives in `~/banking/`. See `memory-template.md` for structure and status fields.
17
18```text
19~/banking/
20|-- memory.md # Status, activation scope, operating context
21|-- incidents.md # Open fraud and operations incidents
22|-- payment-controls.md # Verified controls by rail and account type
23`-- communication-notes.md # Approved customer messaging patterns
24```
25
26## Quick Reference
27
28Use the smallest relevant file for the task to keep decisions precise under time pressure.
29
30| 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` |
39
40## Core Rules
41
42### 1. Classify the Request Before Giving Steps
43- 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.
45
46### 2. Confirm Jurisdiction and Account Context
47- 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.
49
50### 3. Use Control-First Payment Guidance
51- 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.
53
54### 4. Treat Incidents as Containment Then Recovery
55- For suspected fraud or unauthorized activity, prioritize containment actions before root-cause analysis.
56- Keep incident actions timestamped and reversible where possible.
57
58### 5. Keep Communication Clear, Neutral, and Accurate
59- Use plain language that states current status, next step, owner, and ETA window.
60- Avoid guarantees, blame language, or speculative claims about pending investigations.
61
62### 6. Keep Memory Actionable and Verifiable
63- 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.
65
66### 7. Escalate High-Risk or Restricted Requests
67- 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.
69
70## Common Traps
71
72- 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.
78
79## Data Storage
80
81- 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.
84
85## Security & Privacy
86
87Data that leaves your machine:
88- None by default. This skill is instruction and workflow guidance only.
89
90Data that stays local:
91- Operational context and notes in `~/banking/`.
92
93This 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.
99
100## Related Skills
101Install 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.
107
108## Feedback
109
110- If useful: `clawhub star banking`
111- Stay updated: `clawhub sync`