Financial services operations scale in a particular way. Product and engineering scale through software. Operations scale through people, at least until someone establishes where the time actually goes.
The reason is structural rather than a failure of management. Financial workflows carry obligations that software alone does not satisfy: a transfer has to be verified, a reconciliation has to be evidenced, an exception has to be documented with the reasoning behind the decision. Each of those is a real requirement, and each generates work that lands on a person.
As volume grows, that work grows proportionally. The operations headcount curve tracks transaction volume closely, which looks like the cost of doing business and is partly a measurement gap.
The gap is specific. Institutions measure transaction volume, cycle time and error rates thoroughly. They rarely measure where the hours go inside the processes that produce those numbers, which means they cannot distinguish the work that regulation requires from the work that a system limitation created.
Key takeaways
- Operational effort in financial services concentrates in reconciliation, verification and exception documentation.
- Regulatory obligation and system compensation produce identical-looking manual work, and telling them apart is the highest-value analysis available.
- Multi-entity and multi-market structures create process divergence that looks like one process on the org chart.
- Irreversibility changes what can be automated: some steps require a person because the error cannot be undone.
- Institutions instrument transactions well and effort poorly, which is why headcount tracks volume.
- Discovery in regulated operations has to reach exception handlers, who are rarely in requirements conversations.
Where the effort concentrates
| Area | Typical manual effort | Why it exists |
|---|---|---|
| Reconciliation | Matching across core systems, payment providers, custodians and entities | Systems disagree on timing, format or field definitions |
| Verification | Confirming counterparty, beneficiary and instruction details | The consequence of an error is severe and often irreversible |
| Exception documentation | Recording the reasoning behind a non-standard decision | Audit and regulatory requirement, rarely supported by the system |
| Status assembly | Building a view of a case across several systems | No single system holds the full picture |
| Regulatory reporting | Compiling data that lives in several places into a required format | Reporting requirements evolve faster than system configuration |
| Cross-entity coordination | Aligning treatment of the same instrument across legal entities | Local rules differ and the global process does not encode them |
The first two rows are where most of the recoverable hours sit in practice, and they are the two most often accepted as inherent.
The distinction that matters most
Manual work in a regulated operation falls into three categories that look identical from a distance.
Required by regulation. The obligation exists, a person has to perform or approve the step, and the documentation has to survive an audit. This work can be supported and cannot be removed.
Required by consequence. No regulation mandates it, but the error cannot be undone. An international transfer sent to a wrong beneficiary produces a loss that is difficult to recover, and the recovery path runs through a counterparty institution rather than through a database. A person checks because the cost of not checking is asymmetric.
Created by a system limitation. Two systems disagree and someone reconciles. A field was never integrated and someone re-enters. A report is not available and someone builds it. None of this is required by anything except the current state of the estate.
The third category is where the recoverable hours are, and it is frequently the largest of the three. It is also the category most likely to be misattributed to the first two, because after enough years a compensating step is described as "what compliance requires" by people who inherited it rather than designed it.
Separating the three requires asking why each step exists and whether the reason still holds. That is a discovery question, and it cannot be answered from documentation, since compensating steps are precisely the ones no document describes.
Why irreversibility limits automation differently here
In most industries the automation question is whether a step is stable and high-volume enough to justify the build. In financial services a second question governs: what happens if the automated step is wrong.
Two properties determine the answer.
Magnitude. The worst plausible outcome of a single wrong output. In financial operations this can reach regulatory exposure, customer financial loss, or a reporting error with statutory consequences.
Reversibility. Whether the state of the world can be restored. A ledger entry can be corrected. A payment sent to a counterparty, a communication to a customer, or a filing to a regulator cannot be unsent.
Steps scoring high on either belong in a recommend-and-approve or diagnose-only arrangement, where the system produces the analysis and a person takes the action. That is not a limitation on automation value, since the analysis is usually the expensive part and the approval is fast.
The error to avoid is treating database reversibility as real reversibility. If a counterparty institution, a customer or a regulator has already acted on the output, no rollback exists regardless of what the system allows.
Effort by cause
Three kinds of manual work, three dispositions
| Cause | How it presents | Disposition |
|---|---|---|
| Regulatory obligation | "Compliance requires it" | Support it, document it, do not remove |
| Irreversible consequence | "We check because we cannot undo it" | Keep the human decision, automate the analysis |
| System limitation | "The systems do not agree" | Integrate or remove, this is the recoverable portion |
The three are indistinguishable in a process map. Telling them apart requires asking why each step exists and whether the reason still holds.
Multi-entity divergence
Institutions operating across legal entities, markets or regulatory regimes accumulate a specific kind of variation.
The same nominal process runs differently in each entity because local rules, local systems and local counterparties differ. Some of that difference is required. Some of it is an adaptation made years ago for a reason that has since changed, retained because nobody had a mandate to revisit it.
From the centre, both look like local complexity. The comparison that distinguishes them requires examining the same process across entities at the same time, which is difficult when each entity is examined by a different team on a different schedule.
Where the comparison is run, a common finding is that one entity takes materially longer or produces more exceptions than the others on the same process, and the cause turns out to be a specific fixable limitation rather than an inherent local requirement.
Why standard instrumentation misses this
Three reasons specific to financial operations.
The measurement is transactional. Core systems record transactions thoroughly. Reconciliation, verification and exception documentation produce no transaction of their own, so the effort they consume is invisible to the systems that measure everything else.
The people who know are not in the reporting chain. The analyst who reconciles two providers every week could describe the mechanism in detail. Nothing in the reporting structure asks them, and the reports they produce describe outcomes rather than the work of producing them.
Compensating work becomes the job description. After enough years, the reconciliation is not experienced as a workaround. Asked to describe their role, the person describes it as the role, because it is.
Where Horizon fits
Horizon is an AI-powered continuous discovery platform. In regulated financial operations its role is establishing which manual work is required and which is compensation.
Discovery Cycles run AI-led interviews across the roles that operate a process, asynchronously and adapted to each role, following up on why a step exists rather than only recording that it does. The Insights Dashboard quantifies the effort per finding and ranks by impact and effort with traceability to source, and the Process Library structures the result into documentation that makes cross-entity comparison possible. The Initiatives Dashboard converts priorities into business cases with owners.
AFAP SURA, a pension fund administrator in Uruguay and part of the regional SURA group, manages retirement funds for thousands of members with a team of 600 employees. Its ANR process, covering international transfers for members living abroad, and its BPC workflows carry exactly the properties described above.
Information was scattered across five systems including the core platform, treasury and banking interfaces. The team had to request status updates continuously to understand where each case stood. An error in an international transfer could produce a financial loss that is difficult to recover, which is the irreversibility condition that governs what can run without a person. Understanding the process had previously required weeks of manual interviews reaching only a small portion of the team.
In under seven days Horizon delivered 63 prioritized insights covering bottlenecks, repetitive tasks and operational risk points, with a complete view integrating all five systems and evidence-based recommendations to improve traceability, reduce risk and accelerate processing. The comparison against the manual approach was three weeks against seven days. The pilot returned 186% ROI.
The composition of the findings is the useful detail. They distinguished repetitive tasks, which are candidates for removal or automation, from operational risk points, which are candidates for better support rather than removal. That distinction is the one this guide describes, and it is not derivable from a process map.
That is one engagement under specific conditions rather than a projection for any organization.
Diagnostic checklist
- Do you know hours per week per process, per team, rather than only transaction volume?
- For each manual step, do you know whether it is regulatory, consequence-driven or compensation?
- For steps described as compliance requirements, has anyone verified the requirement still exists?
- Do you know which steps are irreversible in the world rather than only in the ledger?
- Have you compared the same process across entities or markets at the same time?
- Do you know how much time goes to assembling a case status across systems?
- Are exception handlers included when processes are reviewed, or only process owners?
- When headcount was last added to operations, was the constraint established or assumed?
- Is there a baseline that would let you demonstrate improvement afterward?
FAQ
What is operational excellence in financial services?
The discipline of improving how financial operations run: reducing manual effort, cycle time and error rates while meeting regulatory and audit obligations. It differs from general operational excellence in that a portion of the manual work is required by regulation or by the irreversibility of the transaction, and cannot be removed.
Why do fintech operations teams grow with transaction volume?
Because reconciliation, verification and exception documentation scale proportionally with volume and land on people rather than systems. Institutions measure transactions thoroughly and effort poorly, so the headcount curve tracks volume without anyone establishing what portion of that work is required and what portion is compensation for a system limitation.
How do you tell required manual work from unnecessary manual work?
Ask why each step exists and whether the reason still holds. Three categories emerge: required by regulation, required because the consequence is irreversible, and created by a system limitation. The third is the recoverable portion and it is frequently the largest, though it is often described as one of the first two by people who inherited the step.
What can be automated in regulated financial operations?
The analysis, generally. The action, conditionally. Steps where a wrong output produces severe or irreversible consequences belong in arrangements where the system produces a recommendation with evidence and a person takes the action. That preserves the control while removing most of the effort, since the analysis is usually the expensive part.
Why do processes differ across entities in the same institution?
Local regulation, local systems and local counterparties differ, and each entity adapted the standard process to its conditions. Some of that variation is required. Some is inherited from a requirement that has since changed. Distinguishing them requires comparing the same process across entities simultaneously, which rarely happens when each entity is reviewed separately.
How do you improve operations without adding headcount?
Establish where the hours actually go per process and per team, separate required work from compensation, and address the compensation through integration, removal or standardization. The constraint in most financial operations is not capacity, it is that nobody has quantified what the existing capacity is spending its time on.
Measure the work, not only the transactions
Financial institutions have solved transactional visibility better than almost any other sector. Every movement is recorded, reconciled and auditable.
The gap is that the work of producing that record generates no record of its own, which is why operations headcount tracks volume and why the recoverable hours stay invisible.
See it. Fix it. Own it.