Portfolio · Financial Operations

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 Capabilities

One dispute pipeline across every channel.

Unified six separate dispute-entry channels into a single processing pipeline.

Direct integration with the bank's Core Banking System (CBS).

Automated identification of commissions, FOREX gain/loss, and auto-reversals.

Duplicate dispute detection and prevention at intake.

End-to-end AES/RSA encryption between systems.

Open API supporting authenticated and unauthenticated dispute registration and status checks.

Context

Why this system was needed.

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 reliable way to validate transactions centrally.
No clear ownership of each dispute.
No protection against duplicate cases and claims.
No synchronization between the systems involved.
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.

The Challenge

The problem wasn't logging a complaint.

The core challenge 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.

Unify multiple intake channels

Accept disputes from multiple channels without losing consistency between where they originated and how they were processed.

Prevent duplicate disputes

Detect when the same transaction had already been disputed before another case entered the resolution workflow.

Trace related financial events automatically

Follow commissions, reversals, FOREX movements, and related transaction activity without requiring staff to investigate each system manually.

Determine transaction ownership

Identify which account, transaction type, and department actually owned the financial event being disputed.

Close the loop with the CBS

Post resolved disputes back into the Core Banking System without requiring manual re-entry.

Protect sensitive financial data

Keep financial information encrypted across intake, investigation, storage, and system-to-system communication.

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

Architecture and platform development.

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

Designing the platform architecture and its integration model with the bank's CBS.

Designing automated transaction-tracing logic compliant with ISO 8583 messaging, enabling integration across compatible CBS environments.

Designing the direct-posting mechanism for resolved disputes.

Implementing backup and recovery architecture.

Implementing the fraudulent transaction reporting and resolution channel.

Designing worker workflows for identification, validation, and reversal of failed transactions without manual intervention.

Building the API layer for dispute registration and status checks.

Building safeguards to ensure the same transaction could not be processed more than once regardless of failure 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

Where the complexity actually lived.

Challenge 01

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

The platform needed to determine what had actually happened financially before a human became involved — tracing commission bookings, FOREX conversions, and prior reversals directly against the CBS and presenting a resolved picture rather than raw data.

Challenge 02

Preventing duplication without slowing down intake

Six channels could raise a dispute for the same transaction. Duplicate detection therefore had to happen at intake, before the case entered the resolution pipeline.

Challenge 03

Closing the loop back into the CBS

Resolution was not complete until the correct systems reflected it. The platform posted transactions, commissions, fees, and the required reference fields back into the CBS so operational state remained synchronized automatically.

Challenge 04

Protecting sensitive financial data across every channel

The platform used AES and RSA encryption for system communication and protected sensitive fields and files in storage, with access controls determining how much information each user could view.

Challenge 05

Making the system accessible without adding operational overhead

The system needed to support both staff and customer access, authenticated and unauthenticated sources, while integrating with the client's existing SSO or Active Directory instead of creating another identity system for administrators to maintain.

Reflection

The workflow wasn't the expensive part. The investigation was.

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 correct GL, and confirming that nothing has already 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.