Building Core Banking Settlement Automation

The core banking team switched to a daily settlement system to solve the problems of duplicate settlements, incorrect settlements, difficulty tracking historical data, and long payout times that came with the existing monthly settlement approach. Moving away from the method of manually processing each settlement type once a month, they separated settlement into 4 stage modules based on the previous day's data each day: recording, payout, payout confirmation, and withdrawal.

The reason for modularizing settlement was clear. When errors occur, you can quickly identify which stage the problem happened in, only the necessary stages can be manually reprocessed, and the execution results of each stage can be managed visibly.

Automation was implemented using a distributed, asynchronous structure based on Celery. Initially, they considered a sequential, call-once approach, but this had the problem that if the order got out of sync, incorrect settlements would occur, requiring manual recovery upon failure. So they designed it so that settlement modules are called multiple times a day regardless of order, with each module preventing its own duplicate execution.

Four mechanisms were put in place to ensure idempotency.

• Every module has a validation stage, and only performs work when conditions are met.
• Already-completed work is made to fail validation, preventing repeated execution.
• Module-level locks are applied so the same module doesn't run concurrently.
• Work within a module is grouped into a transaction, eliminating partial success.

Domain constraints were important in payout optimization. The NongHyup payout API requires money to be split into calls in 100,000 KRW units, so for example 250,000 KRW must be split into 100,000, 100,000, and 50,000 KRW and called multiple times. Since this task is an I/O-bound task affected more by external API response speed than CPU, distribution and parallel processing were more suitable than increasing server performance.

The premise for parallel processing was that each task had to be independent of the others. Since product-specific tasks and payout API tasks don't depend on each other, parallelization was possible, and even though overhead from task splitting and scheduling increased, overall execution time decreased.

Whether all asynchronous payouts succeeded was confirmed later by polling the results that payout tasks left in the DB. The problem of the same task running twice at the same time was prevented by applying an advisory_lock on the DB shared by the application.

As a result, daily settlement made same-day tracking and correction easier than the monthly approach, and parallelizing I/O tasks made payout speed up to 4x faster. Idempotency prevented duplicate settlements, and with a structure that periodically and automatically calls settlement modules, they secured both operational stability and automation together.