Skill: ivangdavila/banking (version 1.0.0)

--- name: Banking slug: banking version: 1.0.0 homepage: https://clawic.com/skills/banking description: Manage retail and business banking workflows with payment operations, account controls, reconciliation, fraud response, and compliant communication. changelog: Initial release with structured banking workflows for intake, operations, incident response, and customer-safe messaging. metadata: {"clawdbot":{"emoji":"B","requires":{"bins":[],"config":["~/banking/"]},"os":["darwin","linux","win32"],"configPaths":["~/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. ```text ~/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`

path: compliance-scope.md
content: # Compliance Scope Boundaries

This file defines what the skill can and cannot do in compliance-sensitive cases.

## In Scope

- Explain operational controls required before transfers.
- Help structure case documentation for audit readiness.
- Clarify which facts are missing before escalation.
- Draft neutral communication updates.

## Out of Scope

- Definitive legal advice for specific jurisdictions.
- Instructions to bypass KYC, AML, sanctions, or approval controls.
- Guidance that enables concealment of suspicious activity.
- Unauthorized handling of customer credentials.

## Mandatory Escalation Triggers

Escalate immediately when any of these appears:

- Sanctions or AML match indicators.
- Request to alter customer identity records without evidence.
- Request to release blocked funds without required approvals.
- Request for legal interpretation presented as final decision.

## Safe Response Pattern

1. State the known facts.
2. State the control or policy boundary.
3. State why escalation is required.
4. Provide the next operational step.

## Reminder

This skill provides operational guidance, not legal counsel.
Always route legal determinations to qualified compliance or legal teams.


path: customer-messaging.md
content: # Customer Messaging Patterns

Use these templates for clear and compliant banking communication.

## Principles

- Lead with current status, not speculation.
- State what action is underway and who owns it.
- Give a concrete next update window.
- Avoid guarantees and legal interpretations.

## Acknowledgement Template

```text
We have received your request and started review under case {ID}.
Current status: {status summary}.
Next step: {action}.
Expected update: {time window}.
```

## Payment Delay Template

```text
Your transfer is currently delayed in processing.
What we have confirmed: {confirmed facts}.
What we are checking now: {active check}.
Next update by: {time}.
```

## Unauthorized Activity Template

```text
We detected activity that may be unauthorized and initiated protective controls.
Current protection: {controls applied}.
Immediate action requested from you: {customer action if needed}.
Next update by: {time}.
```

## Escalation Template

```text
This case now requires specialist review due to {reason}.
Assigned team: {team}.
Current status: {status}.
Next update by: {time}.
```

## Wording to Avoid

- "Guaranteed resolution today"
- "No risk at all"
- "This is definitely legal"
- "The issue is your fault"

Use neutral, factual language and explicit time windows instead.


path: incident-response.md
content: # Banking Incident Response

Use this flow for fraud, unauthorized activity, system outages, or control failures.

## Severity Levels

| Level | Description | Response Target |
|-------|-------------|-----------------|
| P1 | Active fraud or funds at immediate risk | Start containment now |
| P2 | Material payment disruption or repeated failures | Start triage within 15 minutes |
| P3 | Isolated issue with low financial impact | Resolve in normal queue with owner |

## Containment First

1. Stop active exposure:
   - Freeze affected account path when policy allows.
   - Hold pending transactions linked to the incident.
2. Preserve evidence:
   - Keep transaction IDs, timestamps, and control state.
   - Avoid destructive edits to source logs.
3. Notify owners:
   - Operations owner
   - Fraud or risk owner
   - Compliance contact when required

## Recovery Sequence

1. Define scope: customers, rails, and funds impacted.
2. Apply minimal viable fix with rollback plan.
3. Re-run validation checks on one controlled sample.
4. Resume normal processing in staged increments.
5. Monitor for repeat symptoms during the next cycle.

## Communication Cadence

- Internal updates: every 15-30 minutes for P1 and P2.
- Customer updates: when status changes materially.
- Include known facts, current action, and next checkpoint.

## Closeout Requirements

- Root cause statement in one paragraph.
- Control gap and corrective action.
- Owner and deadline for permanent fix.
- Lessons added to ongoing memory notes.


path: intake-checklist.md
content: # Banking Intake Checklist

Use this checklist before proposing any banking workflow.

## 1. Request Classification

- Identify one primary category:
  - Onboarding
  - Payments
  - Reconciliation
  - Fraud or incident
  - Dispute or chargeback
  - Compliance or policy
- If multiple categories appear, pick the immediate blocker first.

## 2. Context Snapshot

Capture these fields in one short block:

- Jurisdiction:
- Customer type:
- Account type:
- Payment rail in scope:
- Urgency:
- Impacted funds or volume:

## 3. Control Readiness

Confirm safety controls before action:

- Ownership and beneficiary validation in place.
- Approval threshold known.
- Dual-control requirements known.
- Cutoff timing known.
- Rollback or recall path known.

If any item is unknown, pause execution guidance and request it explicitly.

## 4. Output Format

Respond with this sequence:

1. Situation summary
2. Immediate safe action
3. Validation checks
4. Escalation condition
5. Next update time

## 5. Escalate Immediately If

- Unauthorized transaction suspected.
- KYC or sanctions bypass requested.
- Irreversible transfer requested without approvals.
- Legal interpretation requested as definitive advice.


path: memory-template.md
content: # Memory Template - Banking

Create `~/banking/memory.md` with this structure:

```markdown
# Banking Memory

## Status
status: ongoing
version: 1.0.0
last: YYYY-MM-DD
integration: pending | complete | paused | never_ask

## Activation
- Auto-activate when:
- Activate only on explicit request for:
- Never activate for:

## Operating Context
- Jurisdiction:
- Customer profile:
- Account types:
- Payment rails:
- Cutoff windows:
- Approval controls:

## Active Incidents
- Incident:
  - Category:
  - Detection time:
  - Containment:
  - Current status:
  - Next action:

## Approved Communication Patterns
- Scenario:
  - Internal update format:
  - Customer update format:
  - Escalation trigger:

## Known Risks and Constraints
- Constraint:
  - Impact:
  - Mitigation:

## Notes
- Decision:
- Follow-up:

---
*Updated: YYYY-MM-DD*
```

## Status Values

| Value | Meaning | Behavior |
|-------|---------|----------|
| `ongoing` | Context is still evolving | Keep gathering operational constraints naturally |
| `complete` | Context is sufficient | Run workflows without setup prompts |
| `paused` | User paused setup refinements | Continue with current context only |
| `never_ask` | User rejected setup prompts | Do not ask setup follow-ups again |

## Principles

- Keep entries brief, factual, and easy to verify.
- Update `last` after every meaningful banking workflow session.
- Store decisions and controls, not sensitive raw account data.
- Preserve incident history with timestamps and explicit outcomes.


path: payment-ops.md
content: # Payment Operations Guide

Use this guide for payment execution and settlement troubleshooting.

## Rail Selection Snapshot

| Rail | Typical Speed | Reversibility | Primary Risk |
|------|---------------|---------------|--------------|
| Internal transfer | Immediate | Medium | Wrong-account routing |
| ACH batch | Same day to next day | Medium | Cutoff miss and return codes |
| Domestic wire | Same day | Low | Irreversible after release |
| Card settlement | 1-3 days | Medium | Chargeback and dispute windows |
| International transfer | 1-5 days | Low | Compliance and beneficiary mismatch |

## Pre-Execution Controls

Before any transfer flow:

1. Confirm sender authority and account status.
2. Validate beneficiary details using approved source.
3. Confirm amount, currency, and fee handling.
4. Check cutoff window and expected settlement time.
5. Verify required approvals were completed.

## Reconciliation Triage

When balances do not match:

1. Verify timing mismatch first (cutoff, weekend, timezone).
2. Check duplicate postings and partial settlements.
3. Compare ledger amount against processor statement.
4. Isolate one transaction ID and trace full lifecycle.
5. Record root cause and prevention control.

## High-Risk Signals

- New beneficiary plus urgent same-day release request.
- Amount far above normal customer pattern.
- Repeated correction requests after approval.
- Manual override request with no documented reason.

Treat high-risk signals as incident candidates and switch to `incident-response.md`.


path: setup.md
content: # Setup - Banking

Read this when `~/banking/` is missing or empty.

## Your Attitude

Be calm, exact, and operationally conservative. Optimize for safe execution, clear ownership, and fast recovery when things go wrong.

## Priority Order

### 1. First: Integration

In the first exchanges, define activation boundaries so this skill triggers in the right banking situations.

- Ask which banking topics should trigger this skill automatically.
- Ask whether to activate proactively for fraud and payment incidents.
- Ask where it should remain inactive and defer to another workflow.

### 2. Then: Capture Operating Context

Collect only context required for accurate guidance.

- Jurisdiction and regulatory environment.
- Customer type (consumer, SMB, enterprise) and account types in scope.
- Supported payment rails and cutoff windows.
- Approval thresholds, dual-control policies, and escalation contacts.

### 3. Finally: Response Preferences

Capture response style preferences that improve reliability.

- Preferred detail level for procedures and checklists.
- Incident posture: speed-first, precision-first, or balanced.
- Escalation style: immediate handoff or staged triage summary first.
- Communication tone preferences for customer-facing updates.

## What to Capture Internally

Keep concise notes in `~/banking/memory.md` and refresh after meaningful changes.

- Activation boundaries and do-not-activate contexts.
- Jurisdiction, account scope, and policy constraints.
- Approved payment controls and known failure points.
- Incident patterns with containment outcomes.
- Customer communication templates that were accepted by stakeholders.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)