Context

A mid-sized bank (under NDA) was expanding its merchant portfolio, but its onboarding process couldn’t keep pace. Sales managers collected seller information in Word or Excel files and emailed that to the Operations Department. Operations staff then manually retyped the data into a legacy Oracle Forms-based system.

This method was time-consuming and error-prone. Onboarding relied on focus and repetition—each staff member could process only 15 to 20 applications per day. As onboarding volumes grew, the inefficiencies became a real blocker to growth.

Replacing the system wasn’t feasible because it was deeply inbuild in the banking core. Any modifications in the banking core were risky and led to the guarantee rejections.

Our Solution

We knew we couldn't just replace a part of a legacy core banking system. Instead, we looked for a smarter way to wrap and slightly change the old process with a new interface, making it faster, safer, and easier to use.

1. Redesigning the Workflow

We started by simplifying the very first step.

• Instead of free-form Word or Excel files, we issued a standardized CSV template.

• Sales managers used this template to submit seller data—or even shared it directly with shopping aggregators to prefill large batches of merchant info.

• This alone cut down time spent gathering and formatting seller information.

2. Building a Simple Internal App

Next, we created a Java 8 based internal web application, aligning with the bank’s tech standards.

• Employees logged in via Single Sign-On (SSO) using Microsoft Active Directory.

• They were greeted with a simple UI with just one field to upload the CSV file.

• Once uploaded, the application displayed the data in a review screen for the operations team. Any mistakes or formatting issues could be quickly corrected in the browser.

• Once everything looked good, the “Onboard” button triggered the process.

3. Integrating with Legacy Oracle System

Because the onboarding merchant module didn’t support APIs, we had to dive deep:

• We analyzed the PL/SQL codebase, identifying which tables, triggers, and procedures handled onboarding.

• After mapping the relationships and logic, we created a new PL/SQL procedure that pre-processed the uploaded data and invoked the original onboarding procedures under the hood.

This way, we preserved all the bank’s existing business logic—without touching the legacy functionality.

4. Keeping Logic in One Place

We made a deliberate decision to keep core business logic in PL/SQL, not Java, for two key reasons:

• The project was under tight deadlines, and re-implementing everything in Java would have consumed weeks we didn’t have.

• We wanted to avoid splitting business logic across layers—this ensured maintainability and allowed a team members to parallelize a job (the one focuses on Java, another one focuses on SQL in PL/SQL).

Outcomes

The results were immediate. Onboarding volume jumped from 15–20 to 110–130 sellers per day (due to banking core system limitations *). Operations no longer wasted hours on manual entry. Instead, they reviewed clean, structured submissions and resolved only exceptions.

The process became faster, more accurate, and auditable. Onboarding became truly scalable—without rewriting the legacy core. The system remained stable, but now worked smarter.

*  We heard the vendor improved the onboarding module of the banking core system. So the bank was allowed to execute even more sellers per day