The Delegated Authority Problems You Won’t Find on a Process Map
Practical lessons from the detail of bordereaux processing, workflow design and operational support
A delegated authority process is relatively easy to describe when everything works as intended. Data is received, validated, mapped and ingested. Tasks move between the right people. Exceptions are resolved and the resulting information feeds downstream reporting and MI.
The day-to-day operation is rarely quite as tidy.
Working with clients on bordereaux, workflows and operational issues brings you much closer to the points where the documented process and the actual process start to diverge. Incoming data doesn't match what was expected. A mapping rule is understood by an experienced user but hasn't been documented. A workflow reaches a scenario nobody anticipated. Or something initially reported as a software problem turns out, after investigation, to have a different cause.
These aren't unusual failures. They are part of running complex delegated authority processes involving different organisations, systems, datasets and levels of operational maturity. The useful question is how well the process deals with them when they occur.
Based on what our teams see in practice, there are several areas worth getting right.
Diagnose the issue before changing the process
When something behaves unexpectedly, the software is a natural place to look first. A bordereau hasn't processed correctly, a workflow hasn't produced the expected outcome or information appears differently from how a user expected.
Sometimes there is a technical defect. In other cases, investigation points to configuration, incoming data, user knowledge or a difference between how the process is designed and how it is understood.
That makes the quality of the initial diagnosis important. When investigating an issue, our teams look for fairly specific information: the environment in which it occurred, the relevant workflow or configuration, the steps required to reproduce it, an example of the affected data, the expected outcome and the actual result. Where possible, reproducing the behaviour in an internal or test environment helps narrow the problem further.
The same discipline applies beyond software support. If a validation repeatedly fails, a bordereau requires manual intervention or downstream MI doesn't look right, the reported problem is only the starting point. The underlying cause might sit several stages earlier.
Changing a workflow before that cause is understood risks accommodating the symptom rather than resolving it. A one-off data issue can become a permanent piece of process logic; a training issue can result in unnecessary configuration; and an undocumented requirement can gradually become another workaround.
Good operational support starts by establishing what happened and why.
Data quality needs to be considered from onboarding through to MI
Data inconsistency remains a recurring feature of delegated authority processing. Bordereaux arrive from different sources, structures vary and information doesn't always correspond neatly with the receiving organisation's expectations.
The effect isn't confined to the point at which the data arrives.
Onboarding establishes much of the context needed later in the process: what information is expected, how it should be supplied and how the organisation intends to use it. At bordereaux receipt, those expectations meet the actual submission. Mapping and ingestion then determine how that information is interpreted and moved into the organisation's systems. The same data ultimately feeds operational reporting and future MI.
A weakness at one stage therefore has a habit of reappearing somewhere else.
An unexpected value at receipt becomes a mapping query. The mapping query requires clarification from the organisation that supplied the bordereau. Processing waits for an answer. If the interpretation isn't captured clearly, the same question can arise on the next submission. If questionable information moves downstream without being resolved, the issue can eventually surface in reporting, where tracing it back to its origin becomes harder.
There will always be queries. The aim shouldn't be to pretend otherwise. What matters is having clear expectations around what is received, what gets validated, how inconsistencies are identified and who is responsible for resolving them.
This also means looking at the process end to end. Improving ingestion in isolation has limited value if the information required to support it wasn't established during onboarding, or if the decisions made during mapping aren't sufficiently clear for the resulting data to be used confidently in MI.
Structured workflows work best when the requirement is understood
A structured workflow is very effective at managing repeatable work. When the required action is known, it provides ownership, consistency, status visibility and a record of what has happened.
But some operational work starts before the requirement is clear.
This distinction matters. A request to perform a defined activity is different from a problem involving an unfamiliar integration, authentication requirement, migration question or unexpected processing behaviour. In the latter case, the first task is usually investigation. Business and technical knowledge need to come together before the requirement can be described accurately enough to execute.
Trying to move that work immediately through a process designed for known requests can create unnecessary exchanges. The workflow asks for definitive information at precisely the point when the people involved are still trying to establish the answer.
Well-designed operations therefore need a sensible route for discovery as well as execution. That might involve an investigation stage, a technical review, a clarification task or a discussion between the relevant business and technical people. Once the problem has been understood, the agreed requirement can move into a more structured workflow.
There is a second benefit to doing this properly. The outcome of the investigation becomes knowledge that can be documented and reused. If the same scenario appears again, it may no longer require discovery at all.
Not every piece of work needs more process. Sometimes it needs the right conversation before the process begins.
Documentation has to reflect how the work is actually done
Process documentation has an obvious governance role, but its operational value is just as important.
A process becomes difficult to follow consistently when the people using it are expected to know rules that aren't written down. This appears in relatively small ways: which information needs to accompany a request, how a particular exception should be handled, which validation takes precedence, or when an issue needs technical review rather than standard processing.
Experienced employees tend to fill these gaps themselves. They know where to look, who to ask and what happened the last time a similar case appeared. Newer employees don't have that history. Two people can therefore follow what they believe to be the same process and arrive at different outcomes.
The same issue appears in technical investigations. If a request requires replication steps, examples, environment details or configuration information, those expectations should be clear to the person raising it. A defined minimum information set improves the quality of the request and reduces avoidable exchanges before investigation can begin.
Documentation should therefore be tested against the work, rather than treated simply as evidence that a process has been documented. Can somebody unfamiliar with the issue understand what information is required? Can they identify the next step? Are the rules they are expected to follow actually available to them?
These questions become even more relevant as firms introduce more automation. If employees struggle to interpret a process consistently from the rules and documentation available to them, those rules aren't yet a particularly strong instruction set for automated decision-making either.
Mapping rules need to move beyond individual experience
Mapping is one of the clearest examples of operational knowledge becoming concentrated in individuals.
People who work with particular bordereaux become familiar with their characteristics. They understand what certain fields mean in context, recognise recurring inconsistencies and remember how previous queries were resolved. That knowledge is useful, but relying on memory makes the process harder to govern and harder to reproduce.
Clear mapping guidelines provide a common reference point.
At a practical level, they should describe the source information expected, the target fields, permitted transformations, validation requirements and the treatment of missing, inconsistent or ambiguous values. They should also establish where deterministic processing stops and a person needs to review the data.
That last point deserves attention. Not every mapping decision should necessarily become another rule. If a value is genuinely ambiguous, the correct action might be to refer it back to the data provider rather than infer an answer. The resolution can then be recorded and, if the same situation occurs repeatedly, the organisation can decide whether it should become part of the standard mapping logic.
This creates a more maintainable process and reduces dependence on the person who happens to know how a particular bordereau has historically been handled.
It also creates a much stronger basis for automation later.
Edge cases need controlled routes, not invisible workarounds
No bordereaux operation is free from exceptions. Queries still need to go back to providers. Data doesn't always conform to expected structures. Particular counterparties have unusual requirements and circumstances arise that weren't anticipated when the process was designed.
A workaround isn't automatically evidence of poor process. Sometimes an unusual case genuinely requires a different treatment.
The risk comes when those decisions remain outside the controlled process.
A spreadsheet is amended manually. An instruction sits in an email. A colleague remembers the agreed treatment. A different route develops for one type of submission. Individually, these are practical responses to getting work done. Over time, they can create a sizeable gap between the process an organisation believes it operates and the one its people actually use.
A controlled exception route should capture enough information to understand what has happened, assign responsibility for resolving it and retain the resulting decision where necessary. For a data issue, that could include the affected record, failed validation, source value, expected value, reason for referral, owner and eventual resolution.
Recurring exceptions should also be reviewed. If the same workaround appears every month, it is reasonable to ask whether it is still an exception. The mapping logic, validation rule, onboarding requirement or workflow itself might need to change.
The objective isn't to remove human judgement. It's to make sure that judgement is visible where it matters and that the organisation learns from repeated interventions.
AI needs rules that people already understand
The discussion around AI in delegated authority is increasingly moving from broad potential towards practical applications. Mapping, validation, document interpretation and exception handling all contain activities worth examining.
But the operational foundations matter.
Take mapping. An AI-assisted process needs guidance on how source information should be interpreted, what transformations are acceptable, which inconsistencies matter and when ambiguity should result in referral rather than an automated decision. If those rules currently depend on the experience of a small number of people, there is work to do before introducing another decision-maker into the process.
The quality of the documentation provides a useful test. If knowledgeable employees can't consistently reach the same conclusion using the rules available to them, expecting an AI system to interpret those rules consistently is optimistic. The ambiguity needs to be understood first.
People remain important for another reason. The teams best placed to identify useful applications of AI are those that understand the process from end to end. They know which activities are repetitive, where time is being lost, which decisions follow established logic and where context or judgement still matters. They can also see the downstream consequence of changing one part of the process.
That leads to more practical uses of AI. A firm might use it to assist with an established mapping activity, identify information requiring review or expedite a repetitive step while retaining human oversight for ambiguous cases. It doesn't need to hand over an entire process for the technology to be useful.
AI works from the operational foundations it is given. Clear rules, understood processes, good documentation and people who know where judgement is required give it a much better starting point.
Designing for the process that actually exists
Process maps are useful because they simplify complicated operations. They show the intended route and help organisations establish roles, controls and dependencies.
They don't always show the phone call needed to understand an unusual requirement, the query sent back to a bordereaux provider, the mapping decision an experienced analyst remembers from six months ago, or the manual intervention that has quietly become part of the monthly process.
Those details matter.
Looking closely at them usually tells you where documentation is weak, where data quality problems originate, where workflows need a proper exception route and where knowledge has become dependent on individuals. It also gives a much more reliable basis for deciding what should be automated.
At Watertrace, we spend a great deal of time working at this level of operational detail: understanding how information enters a process, how it is interpreted, where it moves next and what happens when the expected route doesn't quite work.
For firms reviewing delegated authority processes, bordereaux operations or potential areas for automation, that detail is a good place to start.
Get in touch: info@watertrace.com
Comments