I mapped how bank transactions move through the platform to financial statements, giving disconnected teams a shared basis for design decisions. That work informed changes to system architecture, rule mapping at scale, and cross-system workflows.
The platform is designed to connect daily operational banking systems with formal accounting engines that generate official financial records.
The Core Challenge: Daily banking operations speak Business Data (customer names, loan amounts, transaction codes, and timestamps), while official general ledgers strictly require balanced Debits & Credits. They cannot communicate directly without continuous translation.
What we are solving: Bridging this structural gap so high-volume raw transaction streams are validated, normalized, and mapped into compliant accounting journals automatically—eliminating manual reconciliation workarounds, reducing operational risk, and providing complete financial traceability.
Rethink workflows and navigation using Oracle Redwood. Help existing users learn and adopt the new experience.
I owned the end-to-end redesign, coordinated across teams, and shaped design direction alongside PMs.
Before I could rethink the experience, I had to understand how the whole product worked.
I began by exploring the existing screens and documentation—from data integration and quality checks to accounting rules, reconciliation and reporting. Requirements were organised by module, and each team could explain its own area clearly. What I couldn’t yet see was how those parts connected into one end-to-end journey.
Hover or tap any module below to reveal the unaligned operator requirement.
“I need to compare operational balances with general-ledger balances, find differences, define valid adjustments, and keep evidence of how each difference was resolved.”
I couldn’t rely on a single source of truth. I analyzed AFCS across three core dimensions — what the system said, what the teams knew, and what users actually did.
I reviewed the existing screens and documentation to understand the terminology, the financial domain and what each module did.
I could follow the steps within a feature, but I still needed to understand their purpose. For example, creating an SLA involved entering product information and adding events. That raised more fundamental questions: What does “product” mean here? What counts as an “event”? Why is an SLA needed?
Knowing the steps wasn’t enough. I needed to understand why they existed and how they connected to the wider accounting journey.
I spoke with feature teams, PMs, CSMs and domain experts to understand the purpose behind the modules and how they worked together.
The overall flow began to make sense: banks send data from different sources, but it isn’t ready for accounting. The platform brings that data together, checks and prepares it, then works with the accounting hub and General Ledger to support accounting and financial reporting.
I could now explain how the system was intended to work. But I still needed to understand how people experienced it—what caused confusion, where they got stuck, and what made their work harder.
The team conversations helped me understand how the system was intended to work. Through user research, I explored how people actually navigated it—where they got stuck, what they struggled to understand, and what they did outside the product.
The problem wasn’t just the screens. It was the work between them.
“We download reports and put them in our working files because those are recurring processes, and we need them for our reporting or for adjustments so that we can calculate the needed adjustments.”
I now understood the capabilities, the intended flow and the difficulties users encountered. What I still needed was one connected view showing where those difficulties occurred across the journey.
Instead of asking “How do we improve these screens?”, I began asking:
How do we make the end-to-end work easier to understand and complete?
Operating on theory & specs
Operating on isolated squad silos
Operating on manual Excel workarounds
With the pieces connected, I could tell the story end to end.
The bank has disbursed a loan. Its finance team now needs that transaction reflected in the official financial records.
Scene 1 of 6 · Set up the route
Scroll or swipe to explore the story
Before the loan record can travel, the source system and AFCS need an agreed way of exchanging data.
The team defines the expected information, configures the connection and maps incoming columns to the right fields.
“This is the data I’ll send, what each field means, and how I’ll send it from now on.”
A reusable route for incoming records—not a setup repeated for every loan.
The connection tells the system how data will arrive. Next, it needs to understand what the data represents.
The team configures the subledger application and its events, establishing the context for processing those records.
“This record describes a loan disbursement. Here is the information accounting needs about that event.”
The incoming record has a defined business context.
With the setup in place, the bank sends its loan data through the configured integration. The record is mapped, standardised and checked. Any identified data issues can be investigated and repaired.
Prepared data ready for accounting.
The prepared disbursement event is sent to the accounting system. Accounting rules translate it into debit and credit entries, which are posted to the General Ledger.
The loan transaction is reflected in the bank’s official books.
The journey does not end at posting. Posted journals and ledger balances return, supporting detailed balance calculations and comparison with the bank’s source records.
“Does what reached the ledger match what the bank recorded?”
Differences become visible for investigation.
Finally, the finance team examines the results through reports and analysis—understanding what happened to the data and what needs attention next.
The transaction can be understood, not merely processed.
Simplified product journey. Dialogue illustrates the process; it is not a customer verbatim.
Synthesized 15+ isolated sub-systems into a unified 6-stage lifecycle and uncoupled the platform’s inverted setup wizard into a centralized operational hub.
“A bank's transaction starts life in a source system — before the first file arrives, the environment must map incoming fields, assign ownership, and define ingestion protocols.”
The polished case study doesn't show everything. Not every design decision was straightforward. Some of the most interesting lessons came from the messy parts—in conversations with users, PMs and engineers, in unexpected constraints, stakeholder debates, edge cases, and moments when I had to rethink the problem I started with.