Success Story: Government Savings Bank, Thailand
About the Government Savings Bank
The roots of Government Savings Bank (GSB), Thailand go back to its introduction in 1913 by King Vajiravudh (Rama VI) to provide Thais with an institution to encourage them to save. A state-owned financial institution operating under the supervision of the Ministry of Finance, GSB has almost 1,000 branches reaching every part of the country, offering a broad range of financial products. With 60 million accounts today, Government Savings Bank is one the largest financial institutions in Thailand, and a third of all Thais have an account at GSB.
Real-Time Core Processing
At its core, a bank is a legal custodian of money licensed by a Government authority, and its core system is the legal system of record for the balances of its account holders. While the most common type of core processing system used by large banks is a batch system that is updated once a day, even when front-end applications give the illusion of changes to bank balances in real-time. True real-time systems, even though they simplify bank operations, are frequently used by smaller banks because of the demands they make on their databases. Furthermore, many large banks run multiple back-end core systems, to distribute the computational load, even though this may not give them “360°” views of their customers.
YottaDB’s performance and scalability allows GSB to process all 60 million accounts on a single real-time core system so that all transactions go straight through to the database of record. Logical multi-site functionality allows GSB to keep the application available 24×365, regardless of when its customers wish to bank.
As integrity of balances and financial transactions is critical to the fiduciary responsibilities of a financial institution, GSB operates a message based application. A message with a financial transaction is routed to the next available stateless server process from a pool, and committed to the database as an ACID (Atomic, Consistent, Isolated, Durable) transaction.
Since all state is in the database, any server process can handle a transaction from any client. With real-time replication, even if the processing system goes down and a secondary is switched in within seconds, a user session may not even notice the switchover, since all session state is in the database.