The customer has already explained the problem
A borrower tells your team they cannot keep up with their repayments. Then they tell another team. Someone asks for a document they supplied last week. The account record still shows the old position.
That is an illustrative failure pattern worth designing an AI workflow around. It puts the customer's experience and the work behind it in the same frame.
ASIC's September 2025 hardship review identified improvements where lenders made information collection more flexible and tailored what they requested. It also described better communication before assistance arrangements ended. Those findings offer concrete places to look for unnecessary work and missed follow-through. ASIC Report 815, Hardship, not as hard to get help.
My starting point would be the gap between receiving a request and having a complete, current case that a specialist can act on. Your team should be able to see what the customer has already told you before asking them to say it again.
Give the agent a complete piece of work
Consider an illustrative Australian home-loan hardship request. The borrower has spoken to a contact centre and supplied information through a document portal. A specialist needs the current account position, prior contacts, and any existing arrangement before deciding what happens next.
Define the first agent workflow around that case preparation and its approved follow-through.
| Part of the workflow | Information or action needed | What makes the result useful |
|---|---|---|
| Find the right case | Match the request to the borrower, account, and open support case | Ambiguous matches go to a person before records are combined |
| Assemble the history | Retrieve relevant contacts, supplied documents, and earlier arrangements | The specialist sees a dated sequence with links to source records |
| Identify what is missing | Compare available information with the team's approved requirements | The next request asks only for relevant information still needed |
| Prepare the review | Show the current account position, open questions, and next task | The specialist can make a decision without reconstructing the whole history |
| Execute approved follow-through | Record the decision and make authorised changes in the appropriate systems | Each destination confirms its update; unfinished actions remain assigned |
| Prepare the next review | Bring together the arrangement's status and scheduled contact | The team can act before an agreed follow-up is missed |
The important output is a usable case and a completed next step. A summary in a chat window helps only if it carries enough context for someone to progress the work.
For example, a specialist may approve an arrangement, but the corresponding account update fails. The workflow should keep that action open and route it to its owner. Sending the customer a confirmation while leaving the administration incomplete would create a second problem for the team to resolve.
Make Australian support practices part of the design
Use the language and process your hardship team actually works with: a hardship notice, a statement of financial position, and an existing assistance arrangement. Keep those concepts attached to their source records and the specialist responsible for the case.
ASIC's review described lenders reducing default requests for large amounts of supporting information, including material that was not used. For an agent workflow, that suggests a straightforward design test: can it explain why each proposed request is necessary for this case? ASIC's findings on information collection.
Don't let a generic document checklist become an automatic obstacle. The team should define when it can use information already supplied, when an update is required, and who resolves uncertainty.
The same applies to a financial counsellor or other representative. Establish the recorded authority and the permitted communication route before exposing case information. A workflow that can reach several systems needs to preserve the limits on what it can share between them.
US mortgage servicing needs a separate decision model
US teams often organise this work around loss mitigation. Regulation X describes responsibilities relating to obtaining information, reviewing applications, and communicating whether an application is complete. Its interpretation also distinguishes information required from the borrower from information the servicer needs to obtain elsewhere. CFPB loss mitigation procedures.
That distinction matters operationally. Your internal task to obtain a record should not quietly become another unexplained request to the borrower.
A US workflow needs the servicer's applicable procedures, investor requirements, and review rules. Set those explicitly with the responsible team. Reuse the mechanics for finding records and tracking work where they fit, while keeping the Australian and US decision paths separate.
This becomes particularly useful when a request crosses categories. The customer may be asking for assistance and disputing an account entry. Preserve both issues, with the right owners, rather than letting the first classification erase the second.
Connect the decision to the systems that administer it
You may already have a capable case-management platform. The remaining work often sits around it: a servicing screen, an internal document store, a correspondence tool, or a customised application the agent cannot yet operate.
Building a new assistant does not automatically give it those operations. Someone still has to make the systems usable, carry context between them, and maintain access when the applications change.
Monarch discovers connected applications and makes verified operations available to agents. Its orchestration layer can then run complex workflows across the discovered systems, including legacy and internal software. Access follows the connected account's permissions and what discovery captures and verifies.
For a hardship team, the demonstration should show the full path from the request to the prepared case and the completed approved update. Use the existing case-management and model environment where it serves the business. Add access and orchestration where the workflow still depends on a person moving information between applications.
The permission-aware workflow guide explains how to scope records and actions before expanding a pilot. Once the first path works, the discovered application operations can support adjacent tasks, such as preparing arrangement reviews or reconciling follow-up queues. Each task needs a defined owner and a result the team can verify.
Measure whether the customer gets through the process
A useful pilot starts with cases the team is authorised to review. Include prior contacts, incomplete submissions, conflicting account information, and arrangements approaching their review point. Establish the expected next action with experienced specialists.
Then assess the agent's output against that baseline. Track wrong-account matches, omitted information, unnecessary document requests, and reviewer corrections. In live use, also track whether the approved changes reached every required destination.
Handling time matters, but it should sit beside continuity measures: repeated explanations, abandoned processes, missed follow-up, and reopened cases. Your team needs to know whether the workflow helps a customer reach an appropriate decision and understand what happens next.
Give the specialists time to improve the process as they find exceptions. The person who knows the work needs a clear route to change the workflow, with ownership that continues after the pilot.
The ambition is a service that carries the customer's situation forward. Start by removing the work that makes your people rebuild that situation from scattered records every time they pick up the case.
Bring one case-preparation or arrangement-follow-up workflow to a Monarch workflow discussion, including the systems involved and the point where the work currently stops.
Frequently asked questions
Where should a bank start with AI agents for financial hardship?
Start with a defined piece of case preparation or approved follow-through. Assemble the request, account history and existing documents, identify open questions and prepare the next task for a specialist. Measure completeness and correct execution before extending the workflow.
Does the agent decide who receives assistance?
The workflow described here leaves assistance decisions and exceptions with the authorised team. The agent gathers evidence and performs actions specifically approved for its role. Decision authority should be explicit in the operating design.
How does this differ from a customer-service chatbot?
A chatbot supports the conversation. This workflow also reaches the systems behind that conversation, prepares the case, and completes approved operational actions. A business may use both together.
Can the same approach support US loss mitigation?
The application-access and case-continuity mechanisms can be useful in both markets. US teams must configure their own applicable servicing procedures, requirements, and communications. Australian hardship practices should not be treated as interchangeable with US loss-mitigation rules.