Scenario: Payments and Settlement Team
Design a harness where approval, reconciliation, audit trail, and rollback reduce financial correctness risk.
Key takeaways
- A payments harness treats "looks right" as a financial risk and makes approval policy, reconciliation, audit trail, and rollback the load-bearing elements.
- Risk classification routes changes: operations docs auto-merge, fixture or settlement UI changes need review, and pricing, refund, or tax-field logic hits a human gate.
- Reconciliation checks compare input fixture, expected ledger output, and actual persisted result, failing on minor-unit, tax-rounding, or refund-state mismatches.
- The loop classifies risk before implementation, runs fixture and reconciliation checks, then requires human approval before deploy and a post-deploy audit.
- First 30 days: attach
risk-classification.yamlto pricing and settlement work, require areconciliation-report.mdbefore merge, and wire human gates into workflow, not just docs.
Payments and settlement teams are among the riskiest places to operate without a harness. "Looks right" can become direct financial loss.
Problem Structure
- Small money-logic errors can cause loss.
- Failures may appear only at settlement time.
- Audit logs and approval evidence are needed later.
- Risky changes must be identified before deployment.
Load-Bearing Elements
| Element | Why it matters |
|---|---|
| Approval policy | Separates risky changes from automation |
| Reconciliation check | Confirms correctness, not just execution |
| Audit trail | Reconstructs who approved what and why |
| Rollback plan | Limits damage after a mistake |
Recommended Loop
Artifact Structure
pricing-rules.md
ledger-invariants.md
approval-policy.md
risk-classification.yaml
reconciliation-report.md
audit-log.md
rollback-plan.md
Approval Policy Example
payments_change:
auto:
- "operations docs edits"
review_required:
- "test or fixture changes"
- "settlement UI changes"
human_gate:
- "pricing logic changes"
- "settlement rule changes"
- "refund or cancellation logic changes"
- "accounting or tax fields"Reconciliation Example
reconciliation:
compare:
- "input fixture"
- "expected ledger output"
- "actual persisted result"
fail_if:
- "minor unit mismatch"
- "tax rounding mismatch"
- "refund state transition mismatch"Why This Is Engineering
A payments harness is financial correctness engineering. It uses fixtures and ledger invariants, separates human gates, preserves audit evidence, and includes rollback as part of the design.
First 30 Days
- Attach
risk-classification.yamlto pricing, refund, and settlement work. - Require
reconciliation-report.mdbefore merge. - Connect human gates to workflow, not only docs.