Designing a data-outward case management engine for Bendigo Bank
My role
Product manager (and stand-in designer)
The working team
Technical lead and 3-4 other engineers, Bendigo Bank fraud SMEs as needed
Project duration
About 1 year
The Bendigo bank fraud investigation team had been using a third-party maintained case management system that was built seven years ago. The system was basically a series of forms that allow investigators to capture information about different types of fraud cases. Because the interface didn’t match the complex, fluid reality of financial crime, the data degraded – investigators resorted to dumping massive slabs of unstructured text into notes, and haphazardly choosing options for mandatory fields that were actually irrelevant. We were brought in to improve the usability of the system, but the core problem clearly wasn’t just UX/UI – it was a fundamental mismatch between the data model and operational reality.
Discovery: Auditing the system
Along with the requested UX audit, I also spent a large part of the initial discovery auditing the underlying data quality and entity relationships. Some issues I uncovered:
- Junk data – rigid UI validation was forcing users to input junk data just to close cases which sometimes rendered downstream analytics useless;
- Data siloing – high-leverage investigative patterns could not be surfaced or aggregated because core operational concepts were trapped inside unstructured text blocks or the data was not correctly structured;
- Metric loss – key regulatory and business intelligence metrics were impossible to extract because input constraints did not map to the true data schema.
After considering all the problems, I shifted our MVP focus entirely – yes, we would rebuild with modern UX patterns in mind, but more importantly we would design from the data tier outward, prioritising structural integrity over UI polish.
Product vision
After this high-level discovery period, it seemed like we had enough information to set an overall direction that could drive more detailed decision-making.
The ideal state
The ideal version of this case management system would be highly efficient so that investigators can focus their energy on complex judgement tasks, not data entry and extraction.
Everything that’s able to be automated would be automated, whether it’s within this system, or between this platform and other fraud detection and management software in the ecosystem.
Data that’s captured would be used to produce live insights that would be surfaced in the investigation interfaces to support any human judgements the investigators need to make. Reporting would be a breeze.
What did this mean for our MVP?
We will ensure we deliver a snappier system with more modern UI to address the user frustrations and increase short-term operational efficiencies, but in order to set ourselves up for continued growth we need to:
design and implement more sophisticated data structures that actually correctly represent the complex data relationships in fraud cases;
revisit business requirements to make sure the data captured actually fit those requirements;
eliminate unstructured data as much as possible, as it makes aggregation and automation difficult;
ensure consistent data collection by building in smarter, dynamic forms with more specific validation.
Our highest priority should be ensuring we have a solid foundation for anything data-related; it’s much easier and less destructive to update UI than to change data structures in subsequent versions.
Data design: defining the primitives
Defining the domain primitives
One of the major problems I found in the existing system was that the data structure was not set up in a way that allowed the team to see the nuances in the data that they need for investigations. For example:
Primitive 1: The “Entity” vs the “Alias”
In financial crime, a name isn’t often a reliable way to identify a perpetrator, yet in the legacy system, it was the key identifier in the profiles. Often the same person would commit crimes under different names, but the patterns were hard to spot because each of these were logged under different profiles. I remodeled the data layer to allow attaching multiple names to an entity as “aliases” – this allowed the system to easily identify between a repeat offender striking under different names. By treating the 'Entity' as a core primitive decoupled from a specific name string, this logic became infinitely reusable across any fraud type.
Primitive 2: The case-to-entity relationship property
In the legacy system, entities could be linked to a case, but there was no way to understand the nature of the link (e.g. is an entity with lots of links to scam cases a scammer or a particularly susceptible victim?). In my design I included a new property on the links between entities and cases, distinguishing between perpetrators and victims. This structural primitive allows investigators understand the context easily at a glance. This relationship-metadata primitive turned a static link into an analytical capability.
Mapping primitives to business and legal constraints
Working alongside data quality SMEs, I audited all existing legacy forms to align our new primitives with strict banking regulations. We stripped out obsolete fields, structured loose inputs, and defined automated calculation matrices for critical dollar-figure reporting. To future-proof the platform, I ensured our data capture patterns were architected for downstream API compatibility with external fraud-detection software.
UX/UI design: pragmatic UI
We had no established design system, and I intentionally chose not to spend valuable cycles pixel-polishing individual screens. Instead, the UX design focused entirely on layout hierarchy, managing cognitive load, and matching the specialist user’s mental models correctly. The UI was treated as a clean, economical expression of the underlying data model, ensuring a fraud analyst could interpret multi-variable risk profiles at a single glance.
Delivery and release
Operating as a hybrid PM and designer, I bridged the gap between domain experts (fraud investigators) and the engineering squad. Because I co-designed the data architecture alongside the tech lead, I could write technical specifications and slice the system deployment into clean, independent epics that maximized engineering velocity.
Outcome
Historical data was imported from the existing platform, and the new platform went live in May 2025. Cutover was done in one go since the old system offered no way to sync data dynamically.
The new platform has been used day to day by the fraud operations team since. Though I left the company too soon to have seen any measured results, our calculations projected that we would save the team at least 36 hours for every 1000 cases they processed. More importantly, the data structure now allowed correct, streamlined reporting, and set the foundation for the next round of integrations.