BLOG
backYou pay for groceries with your card, and a few naira tuck themselves away automatically. You buy data, same thing. You fuel your car, same thing. That's the idea behind Save-As-You-Transact (SAYT), our savings feature that helps you save a set amount every time you spend. Whether it’s a transfer, airtime, data, or a bill, money goes into your savings, and you can withdraw anytime for free. Until recently, it had one blind spot: card transactions weren't included. That is, until now.
Whether you’re curious, as I was, to dismantle the entire Save-As-You-Transact (SAYT) infrastructure to see what makes it tick, or you’re a vibe coder looking to learn about building the future of savings, I’ve saved you a spot in my conversation with Adrian, who’s our Business Lead for Savings at Moniepoint.
Savings 101
Humans have always found ways to save money without effort or institutions, and each generation's version has been shaped by the infrastructure around them. The clay pot buried in the ground was the technology of its time. The ajo collector was the technology of another time. The bank account was the technology of another.
What makes each of these feel effortless in their context is that they were embedded in behaviour that was already happening. If you’ve ever used our target savings feature, which we wrote about HERE, you already understand the basic appeal of saving with Moniepoint.
With SAYT, the intuitiveness of our savings feature is even more so: you set a rule, save 10% of every transfer, or N500 every time you buy airtime, and then you stop thinking about it. The money moves by itself. You come back weeks later and find a small pot waiting for you, built up from transactions you had already forgotten you made. It is, at its core, a product that does its best work when you are not paying attention to it.
The first consideration in building a savings feature is recognising that for many people, spending is easy, but saving can be hard. So you meet the customers where they spend. Card payments, purchases at grocery stores and fuel stations, online checkouts, and the everyday spending that, for many people, makes up the bulk of how they actually move money had to be included in SAYT.
Engineering SAYT for the present
Perhaps the most important thing to know at this point is that SAYT does not scour your account history to work. Every service inside Moniepoint, the one that handles transfers, the one that handles airtime, the one that handles bill payments, publishes a small event to a shared internal bus whenever a transaction completes. Think of it as each service leaving a note on a shared noticeboard the moment something happens. SAYT reads those notes and acts on the ones that belong to customers with active rules.
The core engineering challenge is this: how does a savings service know that a transaction just occurred elsewhere in the system in real time, without having to look for it?
The answer is an event-driven architecture, and understanding it is easiest if you walk through what happens from the moment a customer transacts to the moment their money is saved.
A transaction completes, and an event is born
When a Moniepoint customer makes a transfer, buys airtime, or pays with their card at a grocery store or fuel station, two things happen at once. The responsible service (the transfer service, the airtime service, the card payments service) processes the transaction and immediately publishes an event. That event is a small, structured record: this customer, this transaction type, this amount, at this time. It is not an instruction to anyone. It is a statement of fact, left on the shared noticeboard the moment it happens.
The event finds its place in the log
That event does not go directly to SAYT. It goes to a distributed streaming platform that sits between every service at Moniepoint that produces events and every service that consumes them. The platform receives the event and appends it to an ordered log called a topic: one for transfers, one for airtime, one for card payments. Events are stored durably here, which means nothing is lost if a service goes down, and a recovering service can replay everything it missed. This is what makes the system reliable without being rigid.
SAYT listens
SAYT subscribes to every topic it cares about and processes events from them with lightning speed. SAYT always knows exactly what message it last processed. Whether it’s running normally or coming back from downtime, it picks up exactly where it left off. No Moniepoint customer's transaction slips through.
SAYT decides whether this one counts
Reading an event is not the same as acting on it. For every event SAYT receives, it checks two things against its data store: whether this customer has an active SAYT plan and whether that plan covers this transaction type.
A Moniepoint customer who has set a rule to save N500 after every transfer, but not for airtime purchases, will trigger a save on transfers but not on data purchases. The transfer service knows nothing about SAYT. SAYT knows nothing about the transfer service's internals. The event is the only thing they share, and that is intentional.
Saving is calculated and executed
If there is a matching active plan, SAYT applies the customer's rule to the transaction amount. A flat amount or a percentage is calculated based on the transaction and debited accordingly. The money moves from the customer's Moniepoint account into their savings. If the debit fails due to an insufficient balance or a transient downstream error, SAYT logs it and surfaces it in the customer's activity view, where they can see exactly what happened and retry if they choose.
Adding card transactions to SAYT was, in this context, a straightforward extension of the existing architecture. The cards service began publishing its transaction events to a topic, in the same format and with the same fields that SAYT already expected from every other transaction type: customer identity, transaction amount, transaction type, and timestamp.
From that point, card events moved through the same pipeline as every other event, with no bespoke logic required on either side. The event bus is the contract. Once both services honour it, the system handles the rest.
Engineering SAYT for the future
According to Adrian, the event bus that SAYT listens to does not need to distinguish between transaction events and other kinds of events. Right now, SAYT is configured to respond to financial transactions, but the underlying system has no such limitation. An event is just a signal that something happened, and that something can be anything at all.
This means that, in theory and in the team's plans, SAYT could eventually respond to events that integrate even more seamlessly into your day-to-day life. A football match result, pulled from a public sports API. A rainfall event in your city, from a weather service. A milestone in a game you play. Anything that can be expressed as an event that a system publishes can, in principle, serve as a trigger for savings on Moniepoint. You could tell SAYT to put away 1,000 naira every time your team wins, and the system would be listening for exactly that, waiting patiently until the result comes in, and then doing what you told it to do.
The future of savings is something that attaches itself to life rather than just to banking. The card transaction update is, from that perspective, less a destination and more a waypoint. It closes the gap between SAYT and the full picture of your digital spending. What comes next is a much larger expansion of what "spending" and "events" can even mean within the product.
I’ll be sure to take you on that ride too. Until then, keep your dreams alive.
--------------
The future of savings at Moniepoint is bigger than card transactions. If you want to help build what comes next, we are looking for people like you. Explore careers at Moniepoint to get started.
