Playbook
Confirmation policy escalation workflow
When rail risk, amount thresholds, or ambiguous outcomes require human confirmation before progression.
01
Objective
Escalate payments requiring human confirmation when automated policy gates cannot classify risk—preserving audit trails.
02
Prerequisites
- Confirmation policy matrix with amount tiers and rails.
- Escalation roster and after-hours coverage defined internally.
- Audit log for manual confirmations.
03
Operational signals
- Payments exceeding auto-confirm threshold.
- Ambiguous rail outcomes after detection.
- Sanctions or velocity flags (if configured).
04
Decision points
- Confirm versus hold versus reject attempt.
- Temporary fulfillment hold scope.
- Whether to require dual approval.
05
Escalation paths
- Operations analyst → finance controller for material amounts.
- Compliance → legal for flagged jurisdictions if applicable.
06
Failure modes
- Confirming via chat without system record.
- Using explorer screenshots as sole evidence.
07
Recovery patterns
- Record decision with payment_id, actor, timestamp, rationale.
- Apply lifecycle transition through normal provider flow when possible.
- Retries are normal. Webhook delivery is at-least-once. Design consumers to tolerate duplicates and out-of-order arrivals where possible.
- Asynchronous by design. Payers, chains, and your servers operate on different clocks. UI and finance should not assume synchronous finality.
- Eventual consistency. API reads, webhooks, and portal views may briefly diverge during transitions. Reconciliation jobs exist to converge truth.
Walkthroughs: /operations