• Interactive Rewards

Improving API Security In Loyalty And Travel Systems


A recent article on PhocusWire helpfully outlined a range of security vulnerabilities common to loyalty programs.


Some of them were matters of procedure and staff training – which are clearly important – but many were technological vulnerabilities which can be avoided by using modern tools and systems.


Securing loyalty systems is important because of the value of points/miles held by brands and consumers – which makes them attractive to fraudsters – and the significant indirect costs associated with breaches when they take place.


Most loyalty program operators now recognize the urgency of improving their platform security, but are still unsure how to proceed. This article sets out the security characteristics that software buyers should be looking for – particularly with regard to API security, but also covering some key principles that apply to all cases of storing and exchanging customer data.


Minimizing the data needed for API transactions


PhocusWire’s article quotes Steven Puddephatt of GlobalDots, an IT security consultancy, who said,

“There has been a total explosion of APIs across all industries, but especially travel companies. This has left somewhat of a gaping hole in security terms as none of the existing technologies are specifically designed to protect API traffic, and if you’re serious about security you need a specific API protection tool to cover your bases.”

Puddephatt is right to draw attention to the matter of API security, since APIs are specifically designed to share information. A hacker who has access to either of the two connected systems, therefore, can exploit the API logic in order to steal or manipulate data.


Indeed, this was the ‘attack vector’ (method) used in a recent hack on Facebook’s mobile app, in which tens of millions of pieces of data were stolen, without any need for the hacker to crack passwords.


We spoke to Steven Puddephatt after PhocusWire’s article was published, and he reiterated that constant vigilance is required to make sure that hybrid technical architectures are secure. He also mentioned that loyalty systems, in particular, look like honeypots because of the value of points held in member accounts.


Tools to protect API traffic are certainly welcome, but the API itself can be a source of data security if it’s designed to minimize the amount of data that needs to be shared in order to complete a transaction.


To process a financial transaction (including a loyalty points transaction), typically, only 3-4 data fields should be required:

  • the transaction amount – which could be in points, or the amount spent

  • a unique customer identifier – typically the membership ID

  • the loyalty rule(s) that should be applied

  • and, the loyalty currency the customer is earning, exchanging, or redeeming.

Optional fields could include SKU details from the purchase, a transaction ID from an internal system or third-party platform, or a release date (if the points should not be awarded until a future event takes place).


Crucially, none of these fields are PII (personally identifiable information). At Currency Alliance, we believe that completing loyalty transactions based only on the customer’s membership ID is a crucial first line of defence. In fact, over 95% of the transactions taking place on the Currency Alliance platform – which is used by brands with loyalty programs to process transactions between collaborating entities – have no Personally Identifiable Information (PII) included in the API payload.


We also ensure every transaction conducted on our platform is from a known and trusted partner, and that the connection to our API is fully-encrypted and authenticated.

For most brands, processing transactions without PII is possible because accrual and exchange-in transactions can be processed only with the Membership ID in the loyalty program.


Exchange-out and redemption transactions are a little more complicated because the member needs to be authenticated to ensure they are the owner of the loyalty account from which the points/miles value will be taken. We normally implement two-factor authentication on such transactions unless the partner is enabling the transaction behind a secure login.


Minimizing the data needed for a transaction is not a loyalty-specific recommendation, but a longstanding principle of effective information security.


Back in 2014, the government of Estonia created a digital ID system which is used to verify most online retail transactions. In order to authenticate a user, the system queries a central database, asking only for the minimum information needed. To check a customer’s age, for example, it does not ask, “How old is this person?” but merely, “Is this person over 18?”’


In cases where the customer’s payment method needs to be represented, tokens have become the standard approach. Few transactions still carry the 16-digit credit or debit card number; rather, they now typically convert it into a token that is only decipherable by the entities that are a party to the transaction.


Tokens can also be used to validate API connections in a secure way, if the tokens are valid only for a specific function or a limited period of time.


Security best-practices such as these are now widespread across financial services and other related industries. The problem in travel, and particularly in travel loyalty, is that many brands are still operating older systems that have incorporated APIs as an afterthought – rather than systems that were built as API-first.


Technology enabling data best-practices


A lot of legacy technical architecture these days offers a basic API, but these APIs are less secure than those found in modern, API-first systems.


These basic APIs are characterized by generic endpoints which carry out a wide range of transactions. In order to be ‘multipurpose’, these endpoints rely on a lot of mandatory and optional data fields. Multipurpose endpoints are inherently less secure than highly optimized endpoints for specific transactional use cases.


For instance, an API which links and an airline’s loyalty program with a retailer’s loyalty program might exchange details such as SKU information – which might only be relevant to one party.


In 2016, a major hotel group’s reservation system suffered a hack in which, for 327m guests, some combination of the following were taken:

  • name

  • mailing address

  • phone number

  • email address

  • passport number

  • loyalty account information

  • date of birth

  • gender

  • payment card numbers

  • payment card expiration dates

  • two components need to decrypt payment card numbers

  • …and some other non-secure information.

There are dozens of similar examples, but the purpose of this article is not to shame specific brands by bringing up past problems. The point is that legacy software stores a lot of ancillary information alongside the small amounts of information actually needed for any one purpose. Any system connected to this via a basic, generic API would thus become a potential window for a hack that captures a great deal of ancillary data.


Another commonplace legacy problem is the sharing of batch files with transaction data. This presents an additional set of security issues – and you might be surprised by how many batch files are still shared between different parties. These files are normally secured by encryption during transit between systems, but after processing, they often end up on a server somewhere in an unencrypted format. Managing data securely requires ensuring it is secure at every stage of the data processing lifecycle.


Problems such as this characterize technical architecture across travel, and other enterprise loyalty programs. Furthermore, the risk is growing as brands continue to forge new loyalty partnerships based on API connections between legacy systems. These new partnerships are really important to businesses because they expand the appeal of the program and increase customer frequency. But they often expose one or both of the partners to greater risk, because the security of the end-to-end solution is often based on the weakest link.


Considering how many brands are still exchanging data in this way, further breaches, similar to the hotel example above, should be considered an immediate threat.


Wider security benefits of API-first technology


Exposure to risk is one of the primary reasons that many brands are choosing to connect with partners via Currency Alliance. They perceive the API as quite secure, since instead of using generic endpoints which exchange a lot of data for each transaction, it comprises 35 separate endpoints tailored for different purposes. For instance, we have 3 endpoints for different types of accrual transaction. This makes every transaction faster and more secure, while reducing the amount of data included in the transaction.


Furthermore, the ability to consolidate transactions from many other partners via one API connection to Currency Alliance – rather than via dozens of connections with dozens of partners – further reduces vulnerabilities around the platform. We’re proud to say that our API has never suffered a security incident.

Other secure features of the platform include a points bank module (which keeps track of transactions) built according to conventional accounting standards, whereby the debits and credits entered into the ledger are always equal. In many widely-used enterprise systems, 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.


Complying with accounting standards – and recording every transaction to the ledger and every action to system logs – also enhances the auditability for all stakeholders. It also enables rolling back transactions in the event of intentional tampering or careless mistakes.


The points bank also features fraud monitoring: freezing transactions for manual review when potential fraud is detected, or automatically rejecting a transaction that exceeds defined limits. The overall platform 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 which grants access to internal private API endpoints that can manipulate the data and store it securely. This is all done via private API endpoints and not via a public API, so that no third party can figure out the path to sensitive data.


You can read more about the loyalty points bank here.


Working towards a more secure industry


Whichever software a brand uses, for loyalty or in other departments, they should migrate to a microservice architecture in order to take advantage of the benefits of modern, secure technology.


Most enterprises cannot quickly replace their entire loyalty solution. They can, however, replace individual pieces of functionality with API-first software, or can put a thin layer of highly secure, cloud-based software in front of their legacy system to make it much harder for criminals to get access to core systems.


Loyalty fraud is likely to continue to rise over the coming years, as technology makes money fraud more difficult. In the short-term, as the looming recession motivates criminals to increase activity around the most exposed systems that store economic value, loyalty systems are at considerable risk.


It is critical that brands adopt the technology, and the best practices, that have made financial transactions significantly more secure in other industries.


Having spent 30+ years working in financial services, and in the loyalty industry for the past 7 years, it’s clear that loyalty systems remain far less secure than the core systems used by banks to carry out similar earning, redemption, or exchange transactions.

The major difference between banks and loyalty programs, in this regard, is that the travel industry, and most companies with loyalty programs, are not subject to the same level of regulation.


Brands must not wait for regulators to force them to become more secure. The risks to their reputations, and to the loyalty they receive from customers, should be reasons enough to act now.


Learn more about Currency Alliance


Currency Alliance does not provide security auditing or consulting services to third parties. We have, however, been through dozens of security reviews and due diligence exercises by banks, airlines, hotel groups, telcos, utilities, and retailers. We understand, therefore, where vulnerabilities can be found, and we are proud to say our systems architecture and supporting operational practices have passed each review.


An additional benefit is that if you ever want to change core systems, your partners won’t need to integrate with the new systems; they’ll simply remain connected via a stable platform in the middle that switches over to the new system once production-ready.


If you would like to learn more about how securely aggregating partners via a single connection point can reduce your exposure to risk, please get in touch.


This article was first published by Currency Alliance. Permission to use has been granted by the publisher.

2 views0 comments