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. Maker-checker review, role separation, and case-level history keep the request, the evidence, the approval path, the denied attempts, and the action outcome on one record.
All of it runs inside your boundary. Self-hosted on-prem, in your private cloud, or air-gapped, so case data, identity, and the models that read the queue never cross the line your regulator drew.
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.
Most systems that learn from your case data require you to hand it over first
Zendesk, Freshdesk, and Jira Service Management cloud are hosted by the vendor. For a support queue that is a procurement question. For a queue carrying account numbers, sanctions screening hits, and customer identity documents, it is a data-residency question, and it ends most evaluations before the feature comparison starts.
Latch is self-hosted. It runs in your data centre, your cloud account, or a segregated network with no route out. The tenancy, identity, and deployment model is the part your platform and risk teams will read first.
Because it runs inside the boundary, the learning happens there too. Every triage call, every approval, every reject, and every correction an operator makes is signal for the queue you run. The system learns which reversals your team escalates and stops surfacing the ones they never do. None of that becomes training data for a model the vendor ships to somebody else.
On-prem or private cloud
Latch installs in your own data centre or your own cloud account. There is no vendor-hosted tier that case data has to pass through on its way to being processed.
Air-gapped installs
The platform runs with no outbound connection. Reversal and write-off cases stay on the same segregated network as the core banking systems they act on.
Data residency you can evidence
Case records, attachments, and the audit trail stay in the jurisdiction you deploy to. That is the part an examiner asks you to demonstrate rather than assert.
Your identity, your models
Authentication runs against your existing OIDC provider. The model that reads and classifies a case is a plugin, so it can be an open-weights model on your own hardware or an API key you hold.
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.
Blocked attempts are visible
When someone tries to take an action they are not allowed to perform, that attempt is recorded instead of silently hidden.
Full action history
Every action records what was requested, what the external system returned, and whether it succeeded or failed.
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.
One person prepares the case and attaches evidence. Only an approved role can run the reversal, and the preparer is not in it. The result from the payment system is written back to the case automatically.
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.
Does Latch have a built-in approval inbox?
No. Instead of a separate approval inbox, Latch keeps the review step inside the case itself. The case record holds the context, role restrictions, action history, and blocked attempts, so reviewers work from the same place as everyone else.
Can Latch run on-premise or air-gapped?
Yes. Latch is self-hosted. It installs in your own data centre, your own cloud account, or an air-gapped segment with no outbound connection. Case data, attachments, the audit trail, identity, and the AI models that read the queue all stay inside your boundary. That is the difference from Zendesk, Freshdesk, and Jira Service Management cloud, which are hosted by the vendor and process your case data on the vendor side.
How does two-person review (four-eyes control) work in practice?
Latch enforces maker-checker at the system level. One person builds the case: adds notes, attaches evidence, and moves it to the right stage. A different person in the required role reviews and runs the action. The person who prepared the case cannot self-approve. The system blocks the attempt and records it. Both steps happen on the same case, and both are recorded.
What can an auditor see after the fact?
The full case history: the original issue, operator notes, attachments, who tried to act, whether any attempts were blocked, what the external system returned, and the final outcome. Everything is on one record, so reviewers do not need to dig through email threads.
Is this only for large finance teams?
No. A three-person fintech team processing refunds in Stripe benefits just as much as a 50-person payment operations team. The principles are the same: two-person review, role checks, and a record of what happened. The scale is different.
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.