To run one multi country loyalty programme across India, the GCC and Southeast Asia, keep member identity, tier logic and reporting global. Let the catalogue, language and campaign calendar vary by market, all held on a single consumer loyalty platform with one points ledger. Convert points to local value through a parity table owned by finance, store personal data according to the law of each market, and launch in phases so that one market is proven before the next is added. Where legal entities, partner ownership of customer data or regulation prevent a shared ledger, run separate programmes and federate the reporting instead.
Brands end up with three programmes because each country launch is approved against a local budget and delivered by a local lead, so the fastest available solution is chosen in each market. India receives one vendor, the Gulf receives a second through a franchise partner or agency, and Southeast Asia receives a third. Each programme identifies members by whatever the local channel captures, such as a mobile number, an email address or a card number, and each defines its own points value and tier names. The Regional Head of Marketing then inherits three point rules, three tier ladders and three reporting calendars.
Three questions diagnose the condition. Can one person be recognised across all three programmes? Do the tier ladders share a written definition of what each tier means? Can finance state total loyalty liability in one currency on one date? Loyalty liability is the value of points issued but not yet redeemed, which finance records as an obligation.
A useful control is a duplication test. Take members who have transacted in more than one market, normalise their phone numbers and email addresses, and count how many appear as separate people in each programme. The result measures the identity problem before any architecture is chosen.
Member identity, tier logic and reporting must stay global because they are the only places where a member's value across markets is created or measured. Member identity is a single persistent identifier that links every account, contact detail, card and transaction belonging to one person. Tier logic is the rule set that decides which status a member holds, what qualifies them for it and when it lapses. Group reporting is the shared set of metric definitions, currency conventions and reporting dates that makes market results comparable.
Issue the identifier centrally and map each local identifier to it, rather than promoting one market's identifier to master. Matching on phone number alone fails in this region, because members who relocate between India, the Gulf and Southeast Asia often change numbers while keeping an email address. Match on several attributes, merge automatically only above a defined confidence, and send ambiguous pairs to a person for review. A wrongly merged pair is harder to undo than a duplicate, so the rule should err towards leaving records separate.
A status that means something different in each market cannot be honoured when a member moves, so base qualification on points earned rather than currency spent and apply one ladder everywhere.
A local team will reasonably object that one threshold ignores differences in income and spending between markets. The objection is sound, and the answer is to adjust the earn rate, meaning the points produced by a unit of local spend, rather than to build a second ladder. The ladder stays single while the effort required to climb it reflects the market.
Rekyndl is a consumer loyalty platform from The Reward Store, built on a real time event engine. Its design illustrates the requirement: because tier movement is evaluated in real time from events, the earning rule and the tier decision read from one stream of activity, which is the property a shared ladder needs.
Report points issued, redeemed, expired and outstanding in local currency and in one group currency at a stated rate and date. Report tier movement by home market and by the market where activity occurred, since the gap between the two shows cross border behaviour that three separate programmes never reveal.
Catalogue, language and campaign calendar should stay local because they decide whether a reward is wanted, understood and correctly timed, and those judgements depend on the market. Catalogue localisation is the practice of adjusting reward choices, merchant partners and fulfilment so that each market sees rewards it values and can lawfully receive. Language handling is the set of rules that decides which language, script and reading direction a member sees.
Some reward categories are restricted or unsuitable in parts of the Gulf, delivery reliability differs between metropolitan and regional locations in India and Indonesia, and the gift card brands members recognise differ by country. A catalogue built in one market and translated into another usually carries rewards that cannot be delivered or that nobody recognises.
Store a language preference on the member record and do not infer it from the country. A member in Dubai may read English, Arabic, Hindi, Malayalam or Tagalog, and a member in Singapore may prefer English, Mandarin, Malay or Tamil. Arabic requires right to left layouts, so templates, tier badges and emails must be tested in that direction before launch.
Ramadan and Eid, Diwali, Lunar New Year and Hari Raya move against the Gregorian calendar or differ by community, so a calendar built on fixed dates places promotions in the wrong weeks. Keep one central calendar for group commitments and let each market add its own occasions above it.
Issue points in one unit on one ledger and convert to local value at redemption through a versioned parity table owned by finance. Point parity is the rule that states how much local currency value one point carries in each market. Three models are in common use.
Several Gulf currencies are pegged to the US dollar, so parity among them changes little, whereas the Indian rupee and most Southeast Asian currencies move against the dollar. Record the parity table version on every redemption and give members notice before any change.
The less obvious control is to apply market specific rates on earning and parity on redemption. This preserves local economics without a second currency. Decide deliberately whether members may redeem in another market's catalogue, since a higher point value there will attract redemptions.
Under IFRS 15, or Ind AS 115 in India, points generally give rise to deferred revenue until they are redeemed or expire. Breakage is the portion of issued points that is never redeemed, which finance estimates when recognising revenue, and it should be estimated per market because redemption behaviour differs. Confirm the indirect tax treatment of points, such as GST in India and Singapore and VAT in the UAE and Saudi Arabia, with tax advisers for each entity.
Residency is decided by data category and by market, so the safe design holds personal data in the region whose law requires it and lets only tokens and aggregates cross borders. Data residency is a legal or contractual requirement that specifies where personal data may be stored and processed. The table is a starting point for the Data Protection Officer and legal counsel. It is not legal advice, and the rules change.
Hold the global member identifier as a token in the central system and keep names, contact details and consent records in the region. Central analytics then receive pseudonymised or aggregated data. The common failure is an analytics warehouse in one region that ingests raw personal data from every market because nobody mapped the fields. The control is a data flow map by field and by market, reviewed whenever an integration is added. Ask any vendor for ISO/IEC 27001 and SOC 2 reports and for the locations where processing occurs.
Launch one market first and add others in phases, because a simultaneous launch tests parity, residency, language, partners and identity at once and makes any failure impossible to isolate.
Consider a hypothetical consumer electronics retailer headquartered in Bengaluru, with company stores in India and Singapore and franchised stores in Dubai. It defines the global spine in India and completes one finance close. It then chooses Singapore second, because the stores are company owned and the working language matches the home market. Dubai is deferred because the franchisee holds the customer data under its agreement, and a shared programme would need that agreement amended and a lawful transfer basis. Once the agreement changes, Dubai is added third, with Arabic layouts and a Ramadan calendar built before launch.
A single programme is the wrong choice when a licensed or franchised operator owns the customer relationship and will not share data, when a regulator requires a legal entity to keep its own ledger, or when a market sells a different proposition to different customers. In those cases run a separate programme in that market and share only a common tier definition, a mapped identifier where the law permits, and aggregated reporting. Federation is preferable to a forced merge that a contract or regulator will later require you to reverse.
A consumer loyalty platform is software that runs earning, tiers and rewards for a brand's customers. Rekyndl, from The Reward Store, is a consumer loyalty platform with earning rules that respond to any behaviour, including transactional, behavioural, lifecycle, service and custom events. It provides points, tiers and multi user wallets, with tier movement evaluated in real time. Customer journeys and broadcasts are triggered by the same event that drives earning. Coupons and gift cards are supported as reward types, and rewards fulfilment is handled end to end. A no code programme builder is available to marketing teams. It is used across airlines, hotels, banks, retailers and coalition programmes. It does not run employee recognition programmes, channel or distributor incentive programmes, or gift card programmes for retailers.
A multi country loyalty programme uses one member identity, one tier ladder and one points ledger across markets, with local catalogues, languages and calendars layered on top. Three separate programmes each keep their own identifiers, points and reporting, so a person who shops in two markets is two members. The single design makes group reporting and cross border status possible, while the separate design gives each market more autonomy.
Not as a fixed value. Points should sit on one ledger, but their local currency value should come from a parity table that finance owns, versions and reviews on a set cycle. A fixed value across markets drifts from the currency, invites members to redeem where a point is worth most, and misstates loyalty liability. Earn rates can differ by market while the redemption value follows the current parity table version.
Store a language preference on each member record instead of inferring it from the country, then build layouts, emails and tier badges to render right to left for Arabic. Test message templates, mixed content such as English brand names inside Arabic text, and numerals before launch. Keep event names and data fields in one common language so reporting stays consistent across markets.
Sometimes, but the answer depends on the country, the data category and the legal entity. The UAE, Saudi Arabia and free zones such as DIFC and ADGM each set conditions on cross border transfers, and some may require safeguards or regulator involvement. Hold personal fields in the region until the Data Protection Officer and legal counsel confirm a transfer basis, and let only tokens and aggregated data move.
Launch first in the home market, where the customer relationship and data are fully owned, then add the market with the fewest new variables. Compare candidates on script, currency regime, whether a partner owns member data and how demanding the residency rules are. Leave the market with the most new variables until last, and open each market only after the previous one has reconciled through a full finance close.
The information available for this article does not describe multi market configuration, so that point should be confirmed before any decision is made. What is stated is that Rekyndl supports points, tiers and multi user wallets, with tier movement evaluated in real time, earning rules that respond to transactional, behavioural, lifecycle, service and custom events, and coupons and gift cards as reward types.