4 ms·

These are definitely not source of truth customer transactions. Likely auxiliary databases to power various experiences. Like, a customer walks into the bank an

by ponker 6y ago

These are definitely not source of truth customer transactions. Likely auxiliary databases to power various experiences. Like, a customer walks into the bank and the agent needs to know what services to upsell. Or the customer logs into the website and is shown their current portfolio value.

cosmodisk 6y ago
That kind of stuff could have been implemented with any large CRM system(Salesforce,Dynamics,SAP) without any bigger issues.
- threeseed 6y ago
  a) Salesforce is usually out of the question due it not being on-premise. b) Dynamics and SAP are both ridiculously expensive especially since you would be need to also buy additional software e.g. Windows to run it on. Plus of course it's much harder to find specialist engineering talent who know these products. c) All three are far too slow both on the ingestion side e.g. millions of mutations a second and on the read side e.g. feeding into a real-time ML model for an upsell prediction. MongoDB is specifically designed to cater to both of these technical requirements since you can mutate sub-documents and retrieve the full document extremely quickly.
  - cosmodisk 6y ago
    a) I'm not suggesting this for banking transactions- that'd be crazy. However customer service, interactions whilst at a branch, handling all sorts of loyalty programs and etc. To my knowledge, Barclays in the UK use Salesforce for some of these. b) Don't know SAP licensing model but I can't see a major bank not being able to afford $100/month per user for Dynamics/Salesforce. c) They do some offering for these kind of things,but I can't comment on how itd work on such a scale.
sitkack 6y ago
How do you know this?
- ponker 6y ago
  Because no bank in the universe is storing its customer transactions in a bag of 65 relational DBs. It’s all Tandem and IBMz and DB2.

4 ms·

These are definitely not source of truth customer transactions. Likely auxiliary databases to power various experiences. Like, a customer walks into the bank an

by ponker 6y ago

cosmodisk 6y ago
That kind of stuff could have been implemented with any large CRM system(Salesforce,Dynamics,SAP) without any bigger issues.
- threeseed 6y ago
  a) Salesforce is usually out of the question due it not being on-premise. b) Dynamics and SAP are both ridiculously expensive especially since you would be need to also buy additional software e.g. Windows to run it on. Plus of course it's much harder to find specialist engineering talent who know these products. c) All three are far too slow both on the ingestion side e.g. millions of mutations a second and on the read side e.g. feeding into a real-time ML model for an upsell prediction. MongoDB is specifically designed to cater to both of these technical requirements since you can mutate sub-documents and retrieve the full document extremely quickly.
  - cosmodisk 6y ago
    a) I'm not suggesting this for banking transactions- that'd be crazy. However customer service, interactions whilst at a branch, handling all sorts of loyalty programs and etc. To my knowledge, Barclays in the UK use Salesforce for some of these. b) Don't know SAP licensing model but I can't see a major bank not being able to afford $100/month per user for Dynamics/Salesforce. c) They do some offering for these kind of things,but I can't comment on how itd work on such a scale.
sitkack 6y ago
How do you know this?
- ponker 6y ago
  Because no bank in the universe is storing its customer transactions in a bag of 65 relational DBs. It’s all Tandem and IBMz and DB2.