T24 Core Banking System

When creating new technological services for clients, the process often follows these stages: requirements analysis → design → development → testing → production rollout. Each of these steps plays a crucial role in the software development lifecycle. This post focuses on the importance of having a solid service design.

From our experience, we’ve worked with clients who have extremely robust infrastructures, excellent T24 Core Banking implementations, and the latest updates, yet still face performance issues in their systems, because they fail at one critical stage: architecture and service design.

Example Scenario

Let’s consider the following case:

A client needs to implement a bulk payment system in T24.

At a high level, the solution involves three steps:

1. Creating the header with the template information.

2. Adding the payment details (account number, amount, description, etc.).

3. Checking the payment processing status by making multiple requests to the exposed service.

The first two steps don’t present any major issues, since we’re simply sending T24 the necessary data to perform the bulk payment. However, the third step introduces a challenge: we need to know the payment status in real time. Because we don’t know how long T24 will take to complete the task, the same request is sent repeatedly at certain intervals until a successful response is received with the payment status.

Polling: The Hidden Performance Risk

This process, in which the client periodically sends requests to the server to check for updates or status changes is known as polling.

Although it’s easy to implement, it poses a significant risk to system performance.

Disadvantages:

• Inefficient: Many unnecessary requests.

• Higher server load.

• Not real-time: There’s always a delay between polls.

What Solutions Can We Apply?

The optimal approach depends on several factors such as concurrency, API communication methods, and infrastructure setup. In general, the following modern alternatives can be implemented:

Modern Alternatives:

• Webhooks: The server notifies you when changes occur.

• WebSockets / SSE: Real-time communication.

• Design change: Adopting an asynchronous or background (non-blocking) solution.

  
  

Solution in T24 Transact

In T24, we must approach the problem differently. We can’t afford to make unnecessary or heavy requests to T24 while waiting for a response. The optimal solution for intensive processes such as bulk payments is to handle them asynchronously or through queue-based processing.

Alternatives in T24:

• Multithreaded processing using TSA.SERVICE: Once all the payment data is loaded into T24, tasks can be executed through a background service that listens for new payment requests.

  
  

• Queue-based processing with OFS: using the OFS.POST.MESSAGE function allows OFS messages to be queued and processed asynchronously. The idea is to validate payment data first, send the payment as an OFS message, and let T24 queue and execute it without having to wait for a direct response.

  
  

These solutions eliminate the need to wait for a synchronous response from T24 and significantly improve performance. However, to display the results of such processing to the client, another API service should be implemented to check the payment status.

It’s important to emphasize that, in T24 Transact, when exposing services whether web, mobile, or collector endpoints, the APIs should focus on sending and validating client-side data, while letting the Core Banking system handle what it’s designed for: performing financial operations such as applying transactions. This ensures stability and performance by avoiding constant, unnecessary polling of operations.

At Performetriks, our team specializes in software design and can help you optimize your services to ensure the best possible user experience. Don’t hesitate to contact us. We’d be glad to assist you.

Keep up the great work! Happy Performance Engineering!

#ServiceDesign #BankingTechnology #CoreBanking