Treasury, business-side project support and application maintenance: coordinating effectively

A rejected payment, an inconsistent forecast or a change requested by a bank often involves several teams. Coordination between treasury business users, business-side project support and the application maintenance provider helps turn an operational need into a change that is understood, tested and monitored. Everyone should know their role, the decisions required and the evidence to retain.

The approach proposed here by Précis Consulting is an organisational recommendation to adapt to your governance, contracts and operational criticality.

1. Clarify the roles from the outset

Treasury business users define business rules, priorities and payment constraints. They provide use cases, take part in testing and approve the functional outcome within their assigned responsibilities.
AMOA, the French term for business-side project support, helps formalise requirements, assess impacts and organise user acceptance testing. It facilitates communication between treasury and technical teams and tracks decisions and open issues.
TMA, the French term for outsourced application maintenance, means entrusting application maintenance to an external provider. Depending on the contract, it covers corrections, adaptations and enhancements. The provider performs technical diagnosis, estimates the work, produces changes and documents its tests.

Also involve IT owners, operations, security teams and banks when their scope is affected. Maintenance performed by an internal team belongs to the internal application maintenance arrangements; its role should be defined just as precisely.

2. Share a sufficiently detailed request

A common request record helps avoid successive reinterpretations. Describe the process concerned, the expected result, the observed result, the operational impact and the deadline. Add the entity, bank, environment, reproduction steps and useful references. Attachments should comply with confidentiality and data protection rules.

For an enhancement, business-side project support turns the need into verifiable criteria: data to receive, checks to apply, calculation rules, permissions and the result to display. Business users confirm the criteria; the maintenance provider assesses feasibility and identifies technical dependencies.

3. Distinguish incidents, cause analysis and enhancements

An incident first requires an assessment of its impact and a response to restore service. Cause analysis then seeks to understand a recurring issue. An enhancement changes expected behaviour or adds a capability. These activities may be connected while requiring separate decisions and tracking.

Set priorities according to blocked payments, affected users and entities, deadlines and available workarounds. Commitments for acknowledgement, restoration and resolution depend on the contract and agreed service level. Define escalation contacts and the person authorised to decide on an emergency.

4. Establish a traceable decision process

Qualify: business users explain the impact; business-side project support completes and structures the request.
Diagnose: the maintenance provider analyses the evidence, reproduces the issue where possible and proposes an intervention.
Decide: designated owners approve the priority, scope, cost and risks.
Implement and test: the provider performs the work and supplies its technical test results.
Accept: users verify functional criteria with support from AMOA and record the results.
Authorise and deploy: the appropriate owners approve go-live; operations or an authorised provider carries out the deployment.

A closed request should retain the delivered solution, approvals, any limitations and the information needed for ongoing support.

5. Protect payments during changes

Plan interventions around bank cut-off times, payment runs and period-end activities. Separate test and production environments, as well as modification and approval rights. Control the provider’s access and record maintenance activities.

Before go-live, define immediate checks, available owners and the conditions for returning to the previous version. For payments, that return must also address the status of instructions already submitted to avoid duplicate resubmission. Any exceptional procedure should have an identified decision-maker and retained evidence.

6. Example: adapting a pain.001.001.09 file

Fictional example: a bank requests an adjustment to address data in a payment file. Treasury supplies the bank’s requirements and representative cases. Business-side project support documents the expected rules and acceptance scenarios. The maintenance provider adjusts the mapping between source data and the output file, then performs its tests.

Users check data, validations and bank responses within the agreed scope. Go-live follows the required approvals and tests with the bank. Initial submissions are monitored, with an owner assigned to handle rejections.

7. Maintain an effective operating model

Operational tracking addresses incidents, interventions and near-term deadlines. Enhancement governance reviews requirements, dependencies and budgets. Service reviews assess overall quality and contractual commitments.

Select a small set of jointly defined indicators: outstanding requests by age, recurring incidents, compliance with applicable commitments and changes that caused an incident. Specify the period, scope and source for every measure.

Start by checking four elements: an owner for each decision, a common entry point for requests, written acceptance criteria and a shared go-live procedure. Précis Consulting can support this coordination between treasury, business-side project support and application maintenance.