The benefits of a SaaS Loyalty Points Bank
The Points Bank in a loyalty program is the module of software that keeps track of all transactions related to issuing, redeeming, or exchanging points among loyalty program members, partners and other stakeholders. This module maintains the ledgers so that all the transactions, a customer’s points balance, and the outstanding liability of the loyalty program are properly recorded and reported.
Over the past 20 years, the points bank was typically embedded in a monolithic application that also included a loyalty rules engine, CRM functionality, the campaign management system, redemption catalog, and customer-facing screens.
If you are already operating a loyalty program, the chances are, your own points bank is baked into one of these monolithic platforms – so you may never have considered how this module empowers (or limits) your overall loyalty program. However, as awareness grows of the benefits of API-first microservices, some forward-thinking loyalty marketers are beginning to ask whether their points bank is up to the job in delivering the customer value and customer freedoms that are necessary to keep pace with evolving market challenges this decade.
This article answers those questions. First, I explain the core functionality of the points bank and how this varies in different generations of the software.
Second, I explain how a modern, SaaS points bank differs from those typically included in a monolithic platform. The most important difference is in the flexibility that a SaaS points bank confers. It can carry out a wider range of transactions, and allow business professionals to implement enhancements via a management portal, rather than needing IT resources to customize software. It increases your ability to collaborate with new partners, and confers the relative simplicity of technical development that comes with API-first tools.
Third, I briefly summarize the major improvements around security and accounting standards which newer platforms have introduced – and why blockchain is not needed for either.
Finally, I’ll describe where the loyalty industry is heading in the next 10 years, and explain why an API-first points bank will be needed if brands are to keep up with the major developments and customer trends that are already underway.
To answer the obvious question, though: if you’re already running a monolithic loyalty platform, it may be cost-prohibitive to swap out your bundled points bank for a SaaS alternative. However, you can gain much of the same flexibility by connecting your core loyalty platform to a SaaS-based platform, and managing many of the new features via the management portal in the API-connected solution.
*
This is the first article in a two-part series on the core microservices that enable loyalty marketing in modern enterprise architectures. The second article is the Loyalty Rules Engine – the module that varies pricing and rewards based on the context of the transaction, enabling the types of promotion that are familiar from every major loyalty program.
Core functionality of the loyalty points bank
The points bank, combined with the loyalty rules module, form what many people refer to as the ‘loyalty engine’ which enables any form of customer incentive to drive desired behavior.
The points bank comprises:
- datastores related to loyalty transactions, which enables the loyalty team or their loyalty program members to view points balances and transaction histories
- surrounding software functionality to ensure the integrity of the data.
The software functionality surrounding the datastore enables the secure and certain manipulation of data to process transactions as customers earn, burn and exchange points. This software functionality also verifies the accuracy of data, monitors for fraud, maintains a log of all changes, converts the value of points based on the nature of the transaction, and formats the data for storage.
A basic points bank will be able to support issuing and redeeming of points with a single fixed value per point. A more advanced points bank will also enable the loyalty currency to be exchanged with loyalty currencies from complementary partners. Accrual, exchange, or redemption of points are the three basic transaction types.
More sophisticated systems will support additional transaction types such as batch processes, reporting, points expiration, easy reconciliation and settlement among partners, or freezing transactions for manual review when potential fraud is detected.
If the points bank software is designed wisely, it also prevents direct access to the datastore by external software. In the most secure set-up, all access to the points bank data must go through the authentication module embedded in the points bank microservice. This should be via private API endpoints and not via a public API.
In every brand’s loyalty platform, there must be only one main points bank, which serves as the single source of truth for all loyalty transactions. We have run into a number of situations where a company was replicating transactional data across systems in order to improve performance or analytics; this type of replication generally leads to problems as the data gets out of sync.
With the performance levels of a modern, API-first points bank, there should no longer be any good reason to replicate transactional data across systems. Rather, any system that needs loyalty transactional data should simply be able to access that data when needed to perform its desired function. With software-as-a-service (SaaS) solutions, this data can be accessed by any authorized system via an API call.
With a microservices architecture, the points bank can (and should) be a standalone module that fits easily into the broader customer engagement stack of software for any organization.
*
It’s also worth mentioning that points banks can be used in non-points based loyalty programs. In these cases, behind the scenes, a brand is using points to keep track of purchases and other customer actions in order to ‘score’ their account and trigger appropriate incentives. Cashback schemes are an example.
The vast majority of successful programs, however, are points-based. Points are useful because customers understand the incentives and rewards. It’s also fairly easy to hire people who know how to run a points-based loyalty program, and points-based loyalty programs are straightforward to set up and operate.
Flexibility around loyalty incentives
The ‘flexibility’ enabled by the points bank could imply both marketing flexibility, and flexibility around software development.
First, I’ll talk about the marketing flexibility (i.e., the ability to vary the value of points based on the context of the transaction, or the ability to set up new campaigns without IT involvement). Towards the end this article, I go into more detail about the importance of being able to make system changes without the need for IT involvement. But the two are closely interrelated, since the technical flexibility you gain from modern systems also drastically improves your marketing flexibility.
Loyalty marketers should vary the value of their points based on the context of the transaction. This is difficult with basic or legacy points banks. However, to optimize customer value, you should be able to dynamically adjust the value of points based on factors such as:
- the customer’s profile
- whether the inventory is distressed
- and whether a partner is involved in the transaction
…since these are the major drivers of customer value in a loyalty program.
A basic (simple) points bank (such as most loyalty programs management systems that are 10+ years old, or nearly all the apps you can install for small businesses and available in various app stores) will only be able to associate a single value for each point. We have learned over the years, however, that the most engaging loyalty programs are able to dynamically allocate a value per point based on the entire context of the transaction, in order to drive desired customer behavior.
Points in a loyalty system, therefore, should ideally have the ability to take on many values over time, or as the context dictates. There will always be one estimated cost of redemption for all points in circulation; this is known as the ‘base economic value’ (BEV), but the points should be able to have many values depending on how they are redeemed, and by whom. This allows the points to appear to be worth much more than their BEV, so that the perceived value of participating in the program exceeds the actual cost of operating the loyalty program.
One way of achieving this is by sourcing rewards from partners at a cost well below what the customer would pay for the same product or service in cash.
But it can also be achieved in the brand’s own inventory, if the points bank is capable of varying the points value based on the nature of the purchase or the transaction.
For example, a hospitality business might want their points to be worth 25-100% more if redeemed for distressed inventory. Restaurants that are often less busy on Monday, Tuesday, and Wednesday nights might want to assign a much higher value per point on these days of the week to encourage more business during their slower periods.
Similarly: airlines have fairly sophisticated revenue management systems, and they can be fairly sure what number of seats on a particular flight will not be sold. In order to fill those potentially vacant seats, the airline could reduce the number of points/miles necessary to redeem for them. The airline’s cost to put another person on a flight will be less than, say $25, but the customer’s perceived value will be much higher – effectively the cash price of that seat.
Any business with relatively high fixed costs and low-to-modest variable costs can create tremendous perceived value for customers by taking advantage of their distressed inventory in this way.
Points should also be able to have many associated ‘prices’ when they are sold. That may be selling points to partners – as happens when brands collaborate in a loyalty coalition, or in an open loyalty network of complementary partners – or to customers, who will sometimes buy points to reach a threshold at which they can redeem for something of emotional value. It is advantageous to be able to adapt the price per point depending on the customer/partner, the particular campaign, etc.
First-generation points banks, as referred to earlier, lack the ability for their points to take on multiple prices or values depending on business objectives. Second-generation points banks will allow points transactions to be conducted in multiple countries with many different fiat currencies such as US Dollars, British Pounds, Euros, or Pesos.
The most sophisticated points bank, or what we call a third-generation points bank, will allow any point to take on any price or any value depending on the context of a single transaction. That ‘context’ might include the member’s tier level, their recency, or any other information about the customer, the nature of the product or service, the sales channel, or the time/date of the transaction. It might also include whether the points are being awarded for a non-purchase activity that will hopefully increase the lifetime value of the customer.
Imagine millions or billions of points getting issued throughout the year; 85% of those points are typically held for 6-12 months and then most of the points get redeemed for dozens or hundreds of different rewards (all of which have a different cost). The need to make many variations in the prices of points, and keep track of all this activity, with certainty about the accuracy at any moment in time, is incredibly complicated. A third-generation points bank alleviates much of this complexity, since the changes can be made dynamically, based on data exchanged with other systems via API.
The final comment about the role of the points bank is to consider the expiration policy for the points. Points naturally have a lifecycle. The lifecycle of an individual point is typically that it gets generated, then issued to a customer, and then is held by the customer until they are able to redeem.
In our opinion, points should expire under certain circumstances because if points never expire, then the business ends up accumulating liability for points that were given to customers who are no longer engaged with the brand. The points bank should be sophisticated enough to have any fixed or variable time for the points to expire, as well as to adapt the expiration timeframe based on ongoing customer engagement.
Many businesses have adopted the policy that points will expire 24 months after the last transaction with the customer. This policy works well because it encourages the customer to remain active in order to continue collecting points to reach aspirational rewards.
This can, however, be adapted based on the goals of your program. With a SaaS points bank, making such adjustments will be a lot faster than making expensive, hard-coded changes to the points bank that’s built into a monolithic system.
Security & accounting in loyalty platforms
Loyalty programs have been an easy target for fraudsters in recent years, and this is partly because legacy loyalty software lacks the accounting and security features of financial technology. The points bank – as the place where transactions are calculated and recorded – is a key part of the security of a modern loyalty platform.
The majority of points banks do not take accounting standards into consideration. According to accounting standards, all loyalty transactions should be completed in a way where the debits and credits entered into the points bank ledger are always equal. In many systems, however, new points are generated out of thin air when sold to partners or given to customers, and they simply disappear when the points expire or get redeemed. This can make reporting a challenge and often limits a company’s ability to perform audit trail analysis.
One of the reasons blockchain has become so popular in the last decade is because the data stored to a blockchain is immutable. This means it cannot be changed or tampered with. There are ways to make data immutable without recording it to a blockchain. A points bank that follows best practices will prevent the deletion or unauthorized manipulation of any data, and update the data as necessary, maintaining an audit trail (logs) so that the loyalty team can see the entire transaction history, and know who was involved in any changes.
Banking systems have been doing this for decades because of the importance of the audit trail, but most loyalty systems cut corners and violate best practices.
SaaS loyalty points banks accelerate partner collaboration
So far we have only spoken about how the points bank supports a single, standalone loyalty program. Over the past few years, however, the degree of collaboration between brands – using different loyalty currencies, for different business objectives – has grown exponentially. Therefore, it is worth mentioning how an API-first points bank enables easy partner collaboration.
Today, there are millions of loyalty programs and the average consumer may belong to 20 or 30 different loyalty programs. This means the consumer is collecting points in 20 or 30 different loyalty currencies. Because they cannot spend enough money with any one brand to earn enough points in a stand-alone loyalty program to get to interesting rewards, they tend to end up with a modest number of points spread across dozens of programs. This degree of fragmentation means that consumers have low perceived utility for the points in most programs.
You don’t want customers to perceive low value in your points.
Forward-thinking companies are dealing with this by allowing the customer to earn whatever loyalty currency they value most, or at a minimum, allowing their customers to exchange points between programs. This allows the customer to shift value to the program that most motivates them to collect the points in the first place.
By the end of this decade, I anticipate we will see a couple of dozen open loyalty networks where customers can shift loyalty value among complementary brands in order to maximize perceived value. These open loyalty networks may somewhat resemble today’s airline alliances, but they will include banks, retailers, travel companies, utilities, telcos, mobility operators, and so on. Companies will join these networks as they recognize that issuing points, as a customer incentive, is less expensive than merchant-funded offers, discounts, cashback, affiliate fees, or other tactics for customer acquisition and retention. Rental car companies, cruise lines, and many banks figured this out years ago and use loyalty collaborations as a major channel of customer acquisition and retention.
Anyway, the key point here (pun intended) is that the degree of collaboration depends on connectivity between the companies’ points banks, so that collaborating brands can issue, redeem, or exchange their partner’s loyalty currency, or accept their partners’ points as the method of payment in a redemption.
An API-first points bank is critical in this regard, since it easily adapts to data coming in from many different types of partner systems. Without this flexibility, the IT department will have to come up with workarounds that will ultimately affect the integrity and performance of the system. Legacy systems were not designed for connectivity, and while an API might have been added as an afterthought, the majority of platforms do not have the functionality to manage the entire lifecycle of partner collaborations.
At Currency Alliance, we know first-hand the complexity of creating this functionality, because our own SaaS points bank was purposely built to enable such collaboration. We built our first generation points bank in about 4 person months, but then the second generation took an additional 28 person-months of effort. Our latest generation points bank can support every use-case that we’ve heard of, but only after nearly 28,000 hours were invested in our points bank and loyalty rules engine microservice modules.
The standard API from Currency Alliance can be used to access loyalty data, independent of whether we are the main points bank or not. Only about 15% of brands on our platform use Currency Alliance as their main points bank. The other 85% of clients (hotel groups, airlines, retailers, banks, etc.) have their own points bank in some system somewhere in the world. We integrate into those points banks in order to let partners generate accrual, redemption, or exchange transactions – all in real time – and when we are not the main points bank, we simply redirect the inquiry or transaction to the main points bank which is the single source of truth.
That way, our clients don’t need to concern themselves with where the master data is stored, and they don’t have to understand the unique characteristics of each partner’s loyalty system. Using the same standardized API interface, they simply indicate which loyalty program is relevant for that transaction, and the unique identifier of the customer/member. We then transform the data as necessary, take care of all the interfaces to various systems, and handle all the downstream processing.
API-first systems enable similarly simple integrations within your own stack of customer engagement technology. Microservices-based points banks and rules engines can easily be integrated with your CRM or CDP platform, and other modules common to most brands’ marketing platforms such as your enterprise campaign management system, ecommerce solutions across any channel, social media monitoring, etc. The points bank and rules engine’s highly optimized endpoints – which are characteristic of API-first software – make it easy to swap out other components of your technical architecture with only a few coding changes. This gives your company considerable flexibility to embrace best-in-class solutions as they evolve over time.
You can also enjoy such technical simplicity in your own loyalty program if you use a SaaS points bank – but inevitably, many brands will take some time to evolve their technical architecture, and will continue to make individual changes to their legacy systems.
Unfortunately, many of the described requirements for the points bank are often not considered when a development team starts the journey to build or customize their loyalty solution. This results in initial development estimates coming in well under what will be required for a loyalty program to remain competitive this decade.
Don’t be fooled by thinking it is easy to meet business requirements. A fairly simple project may be sufficient to meet known requirements today, but experience has taught us that requirements evolve and change. As the market and competition change, retrofitting what was initially a simple solution to meet evolving needs and compliance standards will only eat into future budgets, and you will be left with the same problem you started with: a complex, costly, monolithic loyalty platform.
Designing loyalty platforms for customer value
Currently, the development and support costs of using legacy software, and persistent limitations on functionality, are ultimately borne by the customer. The customer experiences this as lower-value loyalty rewards, points devaluations, and unexciting redemptions, as business is forced to pass on the costs of technical development.
In the race to create better customer value, we are now seeing more collaboration among complementary brands, in order for customers to more quickly reach interesting rewards – thereby motivating customers to reach the desired level of engagement.
In such an open loyalty network of complementary brands, points are a useful mechanism to create an economy where the unit of measure in transacting is the points. This is useful because brands don’t have to agree on much in order to achieve results. For example, they don’t all need to embrace the same coalition loyalty currency, they don’t have to issue points with the same base economic value, and they can collaborate across borders.
But operating and growing such a multi-brand ecosystem, with software that was only ever really designed for a standalone loyalty program, is becoming prohibitively challenging.
Working with best-in-class solutions from third parties will almost always reduce the Total Cost of Ownership (TCO) of a software platform, because of the inherent flexibility gained, and the fact that development costs are shared among many clients.
In loyalty, operating software that is purpose-built for collaboration remains the biggest opportunity to cut out around 25% of the costs of running the program and redirect that value towards customers.
Every module in the customer engagement ecosystem stands to be improved if it were replaced by SaaS modules. On the journey to a more open, microservices architecture – which will take years at most brands – loyalty teams should be looking for ways to take advantage of best-in-class software that complements legacy systems until they can be replaced altogether.
Currency Alliance was built for exactly that purpose. The Currency Alliance platform can be added as a thin layer of cloud-based technology, to breathe new life into aging systems – greatly reducing the dependency on IT resources to implement changes.
Our suite of loyalty software comprises:
- a points bank
- a rules engine
- the Currency Alliance Global Loyalty Marketplace
- various white label screens that can be implemented in just a few hours
…all of which can be accessed as individual software microservices. Simply connect to your existing loyalty platform via an easy API, and you can modernize operations within days.
Visit CurrencyAlliance.com to find out more.
