US Bank is using DataStax Enterprise to overcome legacy and become customer focused
- Summary:
- As one of the largest financial institutions in the States, US Bank needed to rethink its backend architecture to focus on data driven service.
With a history dating back over 100 years, being the fifth-largest bank in the country, with 74,000 employees and $467 billion in assets, it’s unsurprising that US Bank has had to grapple with its legacy as advancements in digital banking take off. Start-up financial institutions, designed specifically for mobile internet, are making headway with customers and traditional banks can no longer assume that their existing clients will stick around.
This is a realisation that has struck US Bank. Speaking at DataStax’s user event this week in Washington DC, Seshu Guddanti, manager of data platforms and AI/ML at US Bank, said:
Your product is commoditised. What’s going to differentiate you at the end of the day is the customer experience. And the product experience that customers will have.
And this customer experience is largely going to be powered by access, and use of, real-time data. Guddanti added:
They need data. And they need data in real time. In financial services, when customers are coming to our website, they’re not actually looking for transactions anymore. What they’re looking for is how that spending of $50 impacts their balance. They’re actually interested in how much they’ve spent with a particular company over the past year.
It’s powered by data, but then you’ve got a small window of opportunity. The small window of opportunity in financial services happens to be when you’re detecting fraud. Or when you’re sending a notification to a customer that their card was swiped. So there’s a lot real-time data that you need to run your algorithms on.
The problem
However, US Bank was faced with an architecture that meant that access to real-time data was challenging. In fact, because of the way it was structured and because of the use of multiple layers of bath processing, the customer was sometimes getting information from the bank that was 48 hours old. The systems were structured like this (apologies for poor photo quality):
A patching fix was made to solve this, but this still had problems. Guddanti explained:
“You see a problem here. The data is 48 hours old. That means the customer experience is going to be very bad and that the customer knows more than we do at any point in time. To get out of this, we patched through a couple of systems to show the right balance. But there are two problems with that. The patching piece is pretty expensive. The performance latency, which takes around three seconds, is too long. For fraud detection you need it less than 200 milliseconds. So this model won’t work. Also, you’re faking your real-time transaction.”
To solve this, US Bank wanted to simplify to a structure that allowed for real-time data access. This meant architecting in a way that the legacy databases published to a Kafka queue, then into DataStax Enterprise, making use of REST APIs. It now looks something like this:
Guddanti said:
It’s much simpler and is actually cheaper to do it this way. And you get all the benefits of higher performance.
New use cases
Guddanti’ s colleague, Bijulal Gopinathan Nair, who manages this online service layer at US Bank, explained how the use of microservices, APIs and DataStax Enterprise has enabled a highly scalable, always available, distributed system that now provides a number of data driven use cases.
Most of these use cases are centred around having a 360 view of the customer. He said:
Earlier what would happen is if there was a customer demand, we would be going through some planning implementation cycle and it would take up to six months to release that feature. By that time the customer would have lost interest in that feature. With this approach we are able to release a feature to the customer in a couple of weeks.
We are using it for customer 360 view. We had all the customer information, preferences, account transactions in there. When they log into the mobile app, we give the microservices API the request and it will give a response time in less than 20 milliseconds. On top of it we had AI/ML to predict or recommend if you’re going to go over your overdraft in a couple of days or in a couple of weeks.
US Bank has also added Solr, which is an integrated search functionality with Cassandra, which should help serve customers better in the branch. He said:
DataStax has done a great job of integrating Solr, so we only inject once and it gets replicated to both the index and the underlying storage. The use case was for when a customer walks into a branch, we used to have to pull that information from the mainframe, which could take time.
When we added search on top of Cassandra, the banker can then using the customer’s phone number, name, address, or any information, can immediately pull the customer profile - or 360 view - information. And that’s all accomplished in less than 50 milliseconds or so.
Finally, and unsurprisingly, US Bank is also making use of DataStax’s Graph capabilities, which analyses the relationship between different sets of data. There is a strong use case at US Bank to use this technology to intercept fraud. He said:
Traditionally, to get a customer 360 view, we needed to write a bunch of queries against that tabular column. But Graph is structured in such a way so that all the customer information is represented as nodes and all of it is related using edges. Like a brain, where neurons communicate to each other using synapses. We are looking to use this for fraud detection. So when a customer logs in, makes a transaction, we know what the IP addresses, locations, being captured from that customers.
With Graph all those nodes are related and if there’s a third party fraud happening, it will be forming a fraud ‘brain’ which will give a higher risk code. We can then stop the transactions and decline the purchases. The Graph use case really helps us to give the customer a personalised experience.