Case management for banking operations, on your own infrastructure
Latch Workflow gives payment and exception teams one place to run reversals, write-offs, refund approvals, and urgent overrides as controlled case workflows. In regulated finance the unit of work is a case; on the help desk side of the same product it is called a ticket, and it is the same record with the same audit trail. These workflow examples require a configured provider built for your downstream system; they are not bundled banking connectors. Configured maker-checker review and case-level history connect the action request, the approval path and the returned outcome. Evaluate role policy and independent evidence retention alongside that workflow.
Evaluate self-hosted ticketing for your deployment controls and ticketing with approvals for the action path. Source code is available on Enterprise; permitted changes depend on the commercial source licence.
record - restrict - execute - prove
Financial exception management breaks when urgency outruns structure
Finance controls do not usually fail on the standard path. They fail on the urgent, unusual, or high-risk path where one operator has too much discretion and the evidence trail gets rebuilt later.
Reversals and corrections
When a customer is affected, teams rush to fix it first and figure out the paperwork later.
Write-offs and adjustments
High-value exceptions need someone to prepare the case and a different person to approve it before anything moves.
Reprocessing
Re-running a failed transaction gets risky when only one person knows the steps, the scope, and what to document.
Urgent overrides
Time pressure is exactly when independent review and clear evidence matter most, and when they are most likely to be skipped.
Make the deployment review concrete before choosing the workflow
A transaction exception can contain account references and customer documents. List where those records, attachments and backups live, then inspect what identity, email, model and provider integrations receive.
Review Enterprise source access and its terms alongside the identity and deployment controls. The source agreement and your operating plan answer different questions.
Use the self-hosted ticketing evaluation checklist to record owners, dependencies and acceptance tests. Bring one reversal or reprocess request through review, execution, failure recovery and a restore test before expanding the rollout.
Self-hosted deployment
Evaluate your data centre or cloud account. Your team owns infrastructure, durable storage, updates, recovery and integration credentials.
Restricted-network evaluation
Map identity, email, model and provider dependencies before choosing a restricted network. Test the intended topology and its failure behavior.
Data residency evidence
Document where case records, attachments and backups sit, and which integrations receive their contents. Verify this against your own policies.
Identity and model choice
Review the configured identity provider and model endpoints. Self-hosting does not automatically keep external inference or email inside your network.
One person prepares. Another reviews. The system enforces it.
Different industries use different terms: four-eyes principle, maker-checker, dual control, segregation of duties. The goal is the same: no single person can both prepare and approve a sensitive action. Latch enforces this at the system level. See how two-person review works inside the case.
The plain-language version: one person prepares, another reviews independently before the action runs. Also called four-eyes principle.
The finance industry term for the same idea. Common in payments, treasury, and any workflow where money moves.
A broader term for shared control over sensitive activity across people, roles, or systems.
The design choice that keeps incompatible responsibilities from collapsing into one role. Also called segregation of duties.
How Latch supports two-person review without pushing control back into Slack
Latch is not another approval inbox. It keeps the case context, role restrictions, actions, and full trail in one record so review and proof happen where the work happens.
One case record
Notes, attachments, status changes, and any actions taken on external systems all stay on the same case.
Role-based access to actions
Only people in the right roles can run sensitive actions. The system checks before anything executes.
Clear permission rules
Who can do what is defined in the system, not passed down through memory or informal agreement.
Authorization checks are testable
Review authorization behavior and security events alongside the case history. Test where each denial is recorded rather than assuming it appears on the case timeline.
Full action history
Action requests and execution outcomes retain the decision path and the response supplied by the provider. Reconcile an uncertain result with the external system.
Audit trail on the case
Who did what, when they did it, and the evidence behind each decision all stay in one place.
Start with the exception paths that are already hard to explain
The first workflows to bring into this model are the ones that already feel painful: not enough evidence, too much informal escalation, or too much reliance on individual memory.
An operator requests the configured reversal action. A different authorized person reviews it, then an authorized executor runs it through the payment provider. The requester cannot approve or execute that request.
The reason, supporting notes, and outcome all stay on the same case instead of spreading across inboxes and spreadsheets.
The option to re-run a transaction only appears when the case qualifies. Success, failure, and any follow-up are recorded in the same timeline.
When a case is handed off to another team, the full context travels with it and the originating team keeps a record of what happened next.
The real test is whether one case can answer the hard questions
Control owners do not want to piece together a story from fragments. They want to open one record and see: what the team knew, who was allowed to act, what happened when someone tried, and what the outcome was.
Read more about the control story
These articles break the topic into terminology, evidence, legal-discovery context, workflow design, and concrete finance examples.
Maker-Checker: Independent Review Before Execution
Four-Eyes Principle, Maker-Checker, and Segregation of Duties: What Actually Differs
What Auditors Need to See in a High-Risk Approval Workflow
How to Run Four-Eyes Control Without Inbox Approvals
Finance Exception Handling Needs Four-Eyes Control
Audit Trails That Answer the Real Questions
Immutable Payment Audit Trails Need Workflow Context
Audit Logging for Compliance Operations
What to Log When Operators Trigger External Actions
Turn Reprocessing from Tribal Knowledge into a Plugin Action
Questions finance and control owners usually ask
Common questions from finance and control teams evaluating whether Latch fits their review and audit requirements.
Where does the approval review happen?
The action request is attached to the case, with its input and review state. Another authorized person can review it and an authorized executor can run it afterward. Approval and execution are separate steps.
Can Latch run on our infrastructure?
Yes. Evaluate self-hosting in your data centre or cloud account, including durable storage, identity, email, provider endpoints and backups. Enterprise source access is available under a commercial source licence. Restricted-network operation needs a dependency review and acceptance testing.
How does maker-checker work in practice?
For a gated action, the action requester cannot approve or execute their own request. Another authorized person reviews it. The reviewer may also execute it if permitted; the product does not mandate a third person or a particular reviewer role name.
What can an auditor inspect?
Case notes, attachments, action requests, approval transitions and returned execution outcomes. Decide retention, privileged access and independent preservation separately. Application records alone are not WORM storage or a compliance certification.
Can we add amount-based approval rules?
Current action gates support none or maker-checker. More complex amount, tier or sequential approval requirements need a specific integration or application design. A useful evaluation starts with one exception and its actual control requirement.
See how a payment reversal would run inside Latch
Pick one real workflow: a reversal, a write-off, or a reprocessing path. The walkthrough follows the case, the two-person review, the audit trail, and where the whole thing is deployed.