In an era of 24/7 banking, legacy batch processes are detrimental to meeting customer expectations. Any downtime, even for a few hours, risks disappointing customers, reputational damage, and loss of competitive advantage. Sticking plaster workarounds offer only a fraction of the service level expected.
The interconnected nature of today’s technology ecosystems means failure in one batch can create a domino effect. How reliant is batch A on the output of batch B? What happens to systems C and D when B’s inputs do not arrive?
Event-driven systems hold the key to providing always-on service to your customers. They can also create a streamlined, modular, customisable and scalable platform to build your institution for years to come.
What is an event?
In most legacy systems, banks rely on the current state of their data. This means two customers with $5,000 in their accounts look the same, no matter the decisions that led to that figure. Perhaps one customer saved every month, putting away money for a rainy day to hit a target. Maybe the other started with a much higher balance but spent regularly. Without the correct data, there’s no way to know.
An event-driven model involves the passing of asynchronous messages through a broker module. This differs from the traditional remote procedure call (RPC) between APIs. Using a broker ensures others can receive the message sent by one service. These recipients can consume the message at their own pace.
An event is a versatile message format stored in immutable logs and received by consumers. It can trigger multiple subsequent events asynchronously or be stored and scheduled indefinitely, awaiting a trigger.
As events are created, they are fixed to domains or consumer nodes. In the case of a bank, these could be channels like lending, accounts, or payments. Events and endpoint consumers operate interdependently; multiple consumers can act on the same event.
What are some use cases for event-driven systems?
Activity-based rewards
Bank A wants to offer loyal customers a rewards-based savings account. The account offers more attractive interest rates, but only for users who deposit a certain monthly amount for savings.
Using events, we can analyse historical data and build a profile that meets these requirements. Should the bank select the profile, careful savers already depositing regularly can be shortlisted for this new scheme and offered access via notifications in their app.
Credit card tracking
Credit cards have due dates. An institution must run an intensive operation to find all the accounts due today. This means reading the primary database and querying thousands of accounts.
Scheduling events circumvents this issue. Instead of waiting until the last moment to query the whole database, an event can fire once a due date is reached for specific accounts.
Payment requests
Company X expects a $1500 advance from its client before the end of the week. It will use the money to order supplies for urgent building work the client is undertaking.
Using events, Company X can be notified in real-time as soon as the $1500 arrives in their account. X could also schedule another event that automates ordering supplies as soon as the money comes in without having to wait for any manual intervention.
Loan lifecycle management
Brian takes out a loan paid in 12 monthly instalments. The bank needs to process each instalment and check that it has been received.
Instead of running 12 massive batch operations on all loan accounts to discover if Brian has paid, it can use events and scheduling. Each monthly instalment is its own scheduled event. Once completed, a new event is set up for the following month.
Events built-in, not opt-in
Legacy platforms also have customisation options. Yet these are often costly “opt-in” decisions, adding script hooks to override the system’s innate behaviour or force it to take different actions. You don’t want that. Select a platform that doesn’t recreate legacy baggage in your new systems.
Pismo allows orchestration on the fly – no mess, no fuss. Our clients can deploy new features, track spending, and cover loan lifecycles without complex code restructuring. Excessive downtime is also a thing of the past. Canary deployment enables staged releases with critical systems uncoupled. Applications move offline without disrupting essential customer functions. Changes to the core no longer involve locking customers from viewing balances, accounts, or other information.
Want to know more about Pismo’s event-driven architecture? Download our whitepaper
