Adding Real-Time Stream Processing to Promote Offers at the Right Time

BNP Paribas Bank Polska, listed on the Warsaw Stock Exchange since 2011, is a member of the BNP Paribas banking group, which spans 71 countries. In Poland, it provides services to retail customers and other segments, including Wealth Management, microbusinesses, SMEs, and corporate banking. The bank supports green initiatives, helping clients transition to a low-carbon economy and funding over 20,500 households to install photovoltaic panels. It is also digitalizing banking processes with innovative solutions in its internet and mobile banking platforms, GOonline and GOmobile. Clients can open accounts using a selfie and schedule appointments through the Booksy app. The bank promotes diversity, social responsibility, and employee engagement through various initiatives, including the Noble Package project. The IT team at BNP Paribas Bank Polska has a history of using Hazelcast for application acceleration and is well-prepared to enhance business capabilities with new technologies.

The business challenge they faced was to increase the adoption of its products to its customer base. The bank’s marketing team identified a set of responses to specific customer situations, which would result in an offer for an upsell/cross-sell product. One straightforward offer would be to promote personal loans to any customer whose bank account balance was low and could not provide the requested amount of cash via an ATM. The “error” notification was captured by the bank, so it was theoretically easy to quickly respond with the right offer to the customer. The marketing team expected that a timelier response would be advantageous for increasing customer conversions, so they turned to the IT team for help. The team had built an elaborate architecture consisting of a services-oriented architecture (SOA) and an enterprise service bus (ESB) that drove data flows across the bank’s operations. All client-facing and back-office applications were linked via the SOA bus. This architecture was the backbone of their IT infrastructure and had been operating very reliably for the bank for several years. Similar to their previous use cases that incorporated Hazelcast, they wanted to retain all of the existing work, and only add components where necessary to add new business capabilities. This was important to ensure they added no major risk of disruption to their existing operations, considering that everything was already working well. However, the batch-oriented infrastructure based on CRM and data warehouse technology meant that it would typically take up to two days to present the customer with an offer. This would not meet the marketing team’s requirements on timely responsiveness.

With their successes with Hazelcast in their prior use cases, it made sense for the team to try Hazelcast in this new initiative. As a fast and easy-to-use stream processing engine, Hazelcast was a natural fit for plugging into their publish/subscribe messaging bus, turning their environment into an event-driven architecture. This would give them the ability to act on events in real-time, especially since they were already capturing information about customer interactions. The data about each interaction (“event”) would not necessarily have a complete view of the customer. It might have customer account information and transaction details, but other information such as customer name and phone number were not included. But this was not an issue since Hazelcast was used as a high-speed customer account and product information repository, which provided enrichment data to create that complete view. This data was sourced by the bank’s mainframe computers and was used across the many different banking channels, including mobile and web. As event data was read by Hazelcast, it was enriched with data lookups in the in-memory data store in a very fast way. This provided the context necessary to make better decisions on how to respond to the customer. The enriched event could then be published back to the bus for downstream processes to use. One example of a downstream action is sending the customer an SMS message about a product offer, which could be sent immediately after the event, if desired by the bank. This implementation gave the marketing team the ability to decide when to contact the customer. The SMS messaging option provided a communications channel that seemed to deliver more relevant and timely information than email. This is especially true if messages can be sent soon after a customer interaction with the bank. One other aspect of their implementation helped to speed time-to-market for future marketing promotions. The IT team implemented a module that runs within the Hazelcast streaming engine that executes promotion rules written in the Python programming language. This was valuable because there were members of the marketing team who could code in Python, so they were empowered to create the business logic for the promotions. This allowed them to run campaigns as they wished, and freed the IT team from having to provide support in getting promotions implemented into the system.

• The main outcome of the marketing initiative was that offer conversions increased four-fold. As a result of pitching the customer at the right time, which was soon after an interaction versus two days later, the offer came across as timely and relevant. And by using SMS, the offers seem personalized for the customer’s needs at the moment, and not like a broadly distributed spam email. After only six months, the initiative became profitable, as the bank is earning money from these proactive campaigns. The efficiency of the system ensures that future campaigns will be inexpensive to launch. And since the new infrastructure was built with extensibility in mind, the opportunity for future profit continues to grow.
• This new initiative was also a big win because it was easy to implement. The IT team estimated that the cost of starting the pilot for Hazelcast in this initiative was one-tenth the cost of using a data warehouse as the core technology. It was easy to get started at low scale to see how the deployment would work, and then scaling from there to a production-ready level was straightforward. The effort took only six months from the start of the first proof-of-concept to the production deployment of the first marketing offer. They have since grown to supporting almost 70 campaigns, which process about 10 million events per day.
• Processing completes in less than 120 milliseconds, which gives the marketing team more than enough responsiveness to react quickly to customer needs. In most cases, promotions had business logic to intentionally delay the customer-facing communications by a few seconds to ensure delivery at the “right” time. The fast responsiveness of the system was useful in creating the performance headroom necessary to support further growth. This was especially important for setting up a pathway for implementing more real-time processing in the bank’s infrastructure.

• Offer conversions increased four-fold.
• The initiative became profitable after only six months.
• The cost of starting the pilot for Hazelcast was one-tenth the cost of using a data warehouse.
• The effort took only six months from the start of the first proof-of-concept to the production deployment of the first marketing offer.
• They have since grown to supporting almost 70 campaigns, which process about 10 million events per day.