> In reality, balance calculations may be taking place at the same time as INSERT operations, and the result could depend on your database’s transaction isolation level, so if you want no mutations to get added when querying balance - locking will be on you.
Welcome to why core banking platforms still have batch and nightly processing aspects. It's not because of a technological deficit. It's because this business is actually really hard to do in a real-time/continuous manner. Operating on a T+1 basis in many areas dramatically reduces the opportunity for mistakes. It's also fantastic for throughput.
Imagine a use case like fraud detection on checking accounts. You can go about a million times faster if you just suck down some flat files dumped out of the core every night and make a decision the following day. Forcing everything into a synchronous context is not essential to provide the illusion of real time banking to the consumer.
julik•7mo ago
I know :-) Moreover - adding a pause inherent in batch processing allows you to have a last-line-of-defence for the intervention of a human operator / human assessment. It's a fine balance between "make the thing go fast" and "make sure the thing never allows fraud"
bob1029•7mo ago
Welcome to why core banking platforms still have batch and nightly processing aspects. It's not because of a technological deficit. It's because this business is actually really hard to do in a real-time/continuous manner. Operating on a T+1 basis in many areas dramatically reduces the opportunity for mistakes. It's also fantastic for throughput.
Imagine a use case like fraud detection on checking accounts. You can go about a million times faster if you just suck down some flat files dumped out of the core every night and make a decision the following day. Forcing everything into a synchronous context is not essential to provide the illusion of real time banking to the consumer.
julik•7mo ago