Run any Skill in Manus with one click

domain-fintechtransaction-processing

Stars14

Forks3

UpdatedMarch 3, 2026 at 12:24

Guides transaction processing: ACID guarantees for financial operations, idempotency (idempotency keys, deduplication), distributed transactions (saga with compensating transactions), settlement workflows, batch processing, reconciliation, and transaction lifecycle state management. Use when implementing payment flows or financial operations.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

rnavarych

rnavarych/alpha-engineer

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Computer Systems AnalystsComputer and Mathematical Occupations·SOC 15-1211

File Explorer

4 files

SKILL.md

readonly

name	domain-fintech:transaction-processing
description	Guides transaction processing: ACID guarantees for financial operations, idempotency (idempotency keys, deduplication), distributed transactions (saga with compensating transactions), settlement workflows, batch processing, reconciliation, and transaction lifecycle state management. Use when implementing payment flows or financial operations.

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

More from this repository

same repository

alpha-core-ai-ml-engineering

rnavarych/alpha-engineer

Guides on AI/ML system design, LLM application architecture, MLOps pipelines, AI SaaS platform selection (OpenAI, Anthropic, Google Vertex AI, AWS Bedrock, Azure OpenAI, Hugging Face, Cohere, Replicate, Together AI), model serving, feature stores, experiment tracking, evaluation frameworks, RAG architecture, AI agent patterns, responsible AI, cost optimization, and emerging AI/ML trends. Use when designing AI systems, selecting AI providers, building LLM applications, setting up MLOps, or evaluating AI architecture patterns.

2026-07-2414

ai-llm-patterns

rnavarych/alpha-engineer

AI/LLM integration patterns: Anthropic SDK streaming with TypeScript, RAG architecture (chunking, embedding, vector search with pgvector), tool use / function calling, model selection guide (Haiku 4.5 vs Sonnet 5 vs Opus 4.8), prompt caching, structured output with Zod, token cost management. Use when building AI features, RAG pipelines, AI agents.

2026-07-2414

mobile-flutter

rnavarych/alpha-engineer

Flutter 3.27+ patterns — Riverpod 2 state with codegen, GoRouter 14+ navigation, Impeller rendering (default on all platforms), WASM web, extension types, on-device AI (firebase_ai, MediaPipe), Patrol 3.x testing, platform channels, performance

2026-03-0514

role-mobileflutter-expert

rnavarych/alpha-engineer

Expert guidance on Flutter 3.27+ (Impeller default on all platforms, Material 3, WASM web, DevTools, Flame), Dart 3.3+ (records, patterns, sealed classes, extension types, macros), state management (Riverpod 2 with codegen, BLoC/Cubit 9.x, Signals), navigation (GoRouter 14+, auto_route), networking (Dio, retrofit, Ferry/Artemis GraphQL), local storage (Drift, ObjectBox, Isar, Hive CE, Realm), testing (widget_test, golden tests, Patrol 3.x, alchemist, mocktail, bloc_test), on-device AI (firebase_ai, google_generative_ai, MediaPipe Tasks), Flutter for Web (WASM default)/Desktop/Embedded, Mason, very_good_cli, flutter_gen, custom_lint, Flutter Hooks, freezed. Use when building or optimizing Flutter apps.

2026-03-0514

alpha-coreci-cd-patterns

rnavarych/alpha-engineer

Designs CI/CD pipelines with build, test, and deploy stages, blue-green/canary/rolling deployments, feature flags, artifact management, and environment promotion strategies. Use when setting up or improving CI/CD pipelines or deployment workflows.

2026-03-0514

alpha-coreapi-design

rnavarych/alpha-engineer

Designs REST, GraphQL, gRPC, tRPC, WebSocket, SSE, and AsyncAPI/event-driven APIs. Covers OpenAPI 3.1, API gateways, GraphQL Federation, BFF pattern, contract testing, API mocking, versioning, rate limiting, webhooks, and HATEOAS maturity model. Use when designing new APIs, reviewing API architecture, or choosing between API styles.

2026-03-0314

name	domain-fintech:transaction-processing
description	Guides transaction processing: ACID guarantees for financial operations, idempotency (idempotency keys, deduplication), distributed transactions (saga with compensating transactions), settlement workflows, batch processing, reconciliation, and transaction lifecycle state management. Use when implementing payment flows or financial operations.

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