Skill

domain-fintech:transaction-processing

Guides fintech transaction processing with ACID guarantees, idempotency keys, saga patterns for distributed transactions, settlement workflows, batch processing, reconciliation, and lifecycle state management. Use for payment flows and financial operations.

SQL

backend

database

npx claudepluginhub rnavarych/alpha-engineer --plugin domain-fintech

Popularity

Parent stars

Parent forks

Invocation

How this skill is triggered — by the user, by Claude, or both

Slash command

/domain-fintech:transaction-processing

User invocable

Model invocable

Inline context

Default effort

Tool Access

This skill is limited to the following tools:

ReadGrepGlobBash

Context Preview

The summary Claude sees in its skill listing — used to decide when to auto-load this skill

- Implementing atomic balance transfers with correct isolation levels

Supporting Files

references/acid-idempotency.mdreferences/reconciliation-lifecycle.mdreferences/saga-settlement.md

SKILL.md

28 lines · ~545 tokens

Similar Skills

saga-orchestration

40.4k

Coordinates distributed transactions and long-running business processes using saga patterns, compensating transactions, and failure handling for multi-service systems.

1 file

antigravity-awesome-skills

saga-orchestration

Implements saga patterns for distributed transactions and cross-aggregate workflows. Covers choreography vs orchestration, execution states, and compensating transactions for multi-step business processes.

superpowers

saga-orchestration

37.9k

Implements saga orchestration patterns for coordinating multi-service transactions, handling failures with compensating actions, and managing long-running workflows using Python templates.

1 file

antigravity-bundle-ddd-evented-architecture

Stats

LanguageShell

Parent stars13

Parent forks1

MaintenanceGood

Last CommitMar 3, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

Stats

Actions

Help us improve

Share bugs, ideas, or general feedback.

Transaction Processing

When to use

Implementing atomic balance transfers with correct isolation levels

Adding idempotency keys to payment endpoints

Designing saga-based distributed payment flows with compensating transactions

Modelling settlement cycles (T+0, T+1, T+2) and netting/clearing processes

Building three-way reconciliation (internal, external, cross-system)

Defining transaction state machines with enforced valid transitions

Core principles

SERIALIZABLE isolation for balance mutations — REPEATABLE READ is the floor, never lower

Idempotency is not optional — every mutating payment endpoint needs a key; at-least-once delivery is a guarantee, not an edge case

Orchestrated sagas over choreography — financial workflows need a single audit trail, not distributed event soup

Compensating transactions must also be idempotent — a failed rollback is worse than a failed forward step

Never delete transactions — COMPLETED, FAILED, REVERSED are terminal; the ledger is append-only

Reference Files

references/acid-idempotency.md — transaction isolation levels, SELECT FOR UPDATE, atomic transfer SQL pattern, idempotency key schema, deduplication with request hashing, exactly-once semantics

references/saga-settlement.md — choreography vs orchestration trade-offs, compensating transactions, saga state machine diagram, settlement cycles (T+0/T+1/T+2), netting and clearing process, idempotent batch processing

references/reconciliation-lifecycle.md — three-way reconciliation (internal/external/cross-system), daily reconciliation process, break resolution SLAs, transaction state machine (PENDING through REVERSED), state transition enforcement

Transaction Processing

When to use

Implementing atomic balance transfers with correct isolation levels
Adding idempotency keys to payment endpoints
Designing saga-based distributed payment flows with compensating transactions
Modelling settlement cycles (T+0, T+1, T+2) and netting/clearing processes
Building three-way reconciliation (internal, external, cross-system)
Defining transaction state machines with enforced valid transitions

Core principles

SERIALIZABLE isolation for balance mutations — REPEATABLE READ is the floor, never lower
Idempotency is not optional — every mutating payment endpoint needs a key; at-least-once delivery is a guarantee, not an edge case
Orchestrated sagas over choreography — financial workflows need a single audit trail, not distributed event soup
Compensating transactions must also be idempotent — a failed rollback is worse than a failed forward step
Never delete transactions — COMPLETED, FAILED, REVERSED are terminal; the ledger is append-only

Reference Files

references/acid-idempotency.md — transaction isolation levels, SELECT FOR UPDATE, atomic transfer SQL pattern, idempotency key schema, deduplication with request hashing, exactly-once semantics
references/saga-settlement.md — choreography vs orchestration trade-offs, compensating transactions, saga state machine diagram, settlement cycles (T+0/T+1/T+2), netting and clearing process, idempotent batch processing
references/reconciliation-lifecycle.md — three-way reconciliation (internal/external/cross-system), daily reconciliation process, break resolution SLAs, transaction state machine (PENDING through REVERSED), state transition enforcement

domain-fintech:transaction-processing

Popularity

Invocation

Tool Access

Context Preview

Supporting Files

SKILL.md

Similar Skills

Help us improve

Help us improve

Find plugins for your project

domain-fintech:transaction-processing

Popularity

Invocation

Tool Access

Context Preview

Supporting Files

SKILL.md

Transaction Processing

When to use

Core principles

Reference Files

Similar Skills

Help us improve

Transaction Processing

When to use

Core principles

Reference Files