Dispute Management System

Home > Portfolio > Dispute Management System

Turning a fragmented, manual dispute process into a single automated platform

A dispute management platform built to unify how financial institutions receive, investigate, and resolve transaction disputes across every channel — call center, branch, CRM, email, mobile banking, and back office — into one system with a single source of truth.

The system was built to address a problem that grows quietly alongside every bank's digital expansion: as self-service and digital channels grow, so does the volume of disputes, and the operational cost of resolving them manually grows right alongside it.

Key metrics

  • Unified 6 separate dispute-entry channels into a single pipeline
  • Direct integration with the bank's Core Banking System (CBS)
  • Automated identification of commissions, FOREX gain/loss, and auto-reversals
  • Duplicate dispute prevention case
  • End-to-end AES/RSA encryption between servers
  • Open API for both authenticated and unauthenticated dispute registration

Context

Financial institutions expand through digital and self-service channels because it grows market share without the cost of new branches and additional back-office headcount. But that growth has a side effect that's easy to underestimate: dispute volume grows with it.

Disputes don't arrive from one place. They come from call centers, branch visits, CRM tools, email, mobile banking, and sometimes the back office itself. Without a unifying system, this created real day-to-day problems for staff:

  • No way to validate the transactions.
  • No clear ownership.
  • No protection duplicate cases and claims.
  • No system synchronizations.
  • Manual intervention resulting in disruption during off hours or holidays

None of this was a training or staffing problem. It was the absence of a system that could own a dispute's state, origin, and resolution path from end to end.

reconciliation system screenshot

The Challenge

The core challenge wasn't building a form to log a complaint. It was building a system that could sit on top of a live core banking system and reason about a transaction's financial state well enough to resolve disputes with minimal manual investigation.

A disputed transaction isn't a single fact — it can involve commissions, foreign exchange conversions, prior reversals, and multiple GL accounts, all of which staff previously had to trace by hand across separate systems.

This meant the system needed to:

  • Accept disputes from multiple channels without losing consistency between them.
  • Prevent the same transaction from being disputed twice.
  • Automatically trace a disputed transaction's related financial events.
  • Identify which account and department actually owned the transaction type.
  • Post resolved disputes back to the CBS without manual re-entry.
  • Keep sensitive financial data encrypted throughout.
  • Give both staff and customers a way to check dispute status without added overhead.
  • Integrate cleanly with a bank's existing user-management systems.

The system therefore needed to function less like a ticketing tool and more like an investigative engine that happened to also manage a workflow.

My Role

I was involved in the architecture and development of the platform, with responsibility spanning the system rather than individual screens or endpoints.

My work included:

  • Designing the platform's architecture and its integration model with the bank's CBS.
  • Designing the automated transaction-tracing logic used during dispute investigation compliant with ISO 8583 message enabling plug and play on any CBS.
  • Designing the direct-posting mechanism for resolved disputes.
  • Implementing the backup and recovery architecture.
  • Implementation of fraudulent transaction reporting and resolution channel
  • Designing worker flow for indentification, validation and reversal of failed transaction without manual intervention.
  • Building the API layer for dispute registration and status checks.
  • Building layer to make sure no transaction goes through more than once no matter the failure reason or point.

The key architectural responsibility was making sure a dispute could move from intake to resolution without staff having to manually cross-reference multiple systems at any point in that journey.

Engineering Challenges

1
Making the system reason about a transaction, not just log a complaint

The hardest part of this system wasn't the workflow around a dispute — it was getting the system to automatically determine what had actually happened to a transaction financially before a human got involved. That meant designing logic capable of tracing commission bookings, FOREX conversions, and prior reversals directly against the CBS, and presenting that as a resolved picture rather than raw data for staff to interpret. This shifted staff's role from investigator to reviewer.

2
Preventing duplication without slowing down intakes

With six different channels able to raise a dispute for the same transaction, duplication was a real operational risk — both for customer trust and for financial accuracy. Catching duplicates after the fact, through manual review, wasn't good enough. Integrating duplicate detection directly against the CBS at the point of intake meant a duplicate dispute could be rejected immediately, before it ever entered the resolution pipeline.

3
Closing the loop back into the CBS

A dispute isn't resolved until the correct systems reflect that resolution. Rather than leaving staff to manually update flags across multiple systems after resolving a case, the platform posted transactions, commissions, and fees directly back to the CBS — including all reference fields required for downstream reconciliation — so resolution and system state stayed in sync automatically.

4
Protecting sensitive financial data across a multi-channel system

With disputes entering through six different channels, sensitive data like card numbers had to be protected consistently regardless of entry point. The platform used a combination of AES and RSA encryption for server-to-server communication, and encrypted sensitive fields and files before storage, with tiered access so authorized users could view data partially or completely depending on permission level.

5
Making the system accessible without adding operational overhead

Disputes needed to be raised and checked by both staff and customers, from authenticated and unauthenticated sources, without creating a maintenance burden for the bank's admin team. The system exposed a multi-stage open API for registration and status checks, and integrated with the client's existing SSO or Active Directory setup rather than requiring a separate user-management system to be maintained alongside it.

Reflection

This project shifted how I think about back-office systems. It's easy to treat a dispute as a workflow problem — something that just needs a form, a queue, and a status field. But the real cost in dispute handling isn't the workflow, it's the investigation buried inside it: tracing commissions, checking for prior reversals, identifying the right GL, confirming nothing's been duplicated.

The highest-leverage work on this project wasn't in the interface — it was in automating the reasoning that used to happen manually, inside someone's head, every time a dispute came in. That's the part of the system that actually removed cost and risk from the bank's operation, and it's the lens I still bring to back-office and financial systems work today.

Get In touch

Feel free to email me at hi@riteshr.au for counsuting work, and I'll get back to you.