NDAX asked for a loyalty programme

Every product publishes what its customers do into one shared layer, in a consistent form. Trades, OTC activity, learning progress, and whatever a future product emits. That layer holds the single customer record the business had been missing.

It matters beyond loyalty, and this was a large part of the argument for building it first:

• Segmentation stops being per-tool. A segment describes a person, and no longer just their behaviour inside one product.
• Machine learning becomes possible. Churn and propensity models need consistent behavioural history across the whole relationship, which is exactly what the layer produces and what per-product records cannot.
• Personalisation has something to personalise against.
• Product decisions get evidence. Which products pull customers towards each other, and which sit unopened, becomes a question with an answer.

The loyalty engine is the first system to read from the unified data layer. Once historical and near-real-time activity from every product is linked to one 360-degree customer view, the same data can support new AI and machine learning use cases. Historical records can train models, while new events can update churn and propensity scores, trigger next-best-action recommendations, refresh lifetime value estimates and flag unusual activity.

The 360-degree view can also show how activity in one product relates to use of another. It could reveal which education activity tends to precede a first trade, which active traders may be ready for staking or where valuable customers begin to disengage. Those insights can uncover new commercial levers and inform changes to existing products, new cross-product journeys or entirely new products.

Almost every loyalty programme in the exchange market is a feature. Somebody writes code saying a customer who trades this much gets that discount. It works, and it is why those programmes change about once a year: every change is a development request, so it queues behind everything else.

We specified something the business assembles, out of four parts it controls separately.

• An event type is something a customer can do. It is held as configuration, so a new signal from any product enters without the system being rebuilt around it.
• An earning rule decides which of those events qualify for a reward.
• Earning conditions attach to a rule and combine with AND and OR. They cover transaction history, time windows and product-based conditions, so a reward can follow a pattern of behaviour and not a single action.
• A reward rule decides what the customer actually receives.

Seven programme types were specified on those four parts, each a different composition of them:

• Points-based, the familiar earn-and-spend balance.
• Progress-points tiered, where accumulated points move a customer up a level.
• Milestone tiered, where reaching a defined achievement does it instead.
• Fixed benefit, a standing entitlement with no accrual at all.
• Referral, with its own qualifying conditions on the invited customer.
• Affiliate, carrying tier rules, performance statistics and payout logic.
• Journey-based, where the order of events matters and the customer is walked through a sequence.

The tiered schemes most fintech businesses start with are one of the seven, and nothing like the whole shape of what is possible.

What that buys NDAX is not mainly a saving on development. It is speed and room to change its mind. A campaign can be built in a working week and switched off in an afternoon. A hypothesis about customer behaviour can be tested with a live programme, which is a great deal more informative than a slide. When the market moves, or a competitor changes its fee tiers, the response is a configuration change made by the people who noticed.

Two requirements exist purely to keep that safe once real customers hold real balances. Programmes and event types were specified with versioning, because a scheme already issuing rewards cannot be edited underneath the people holding balances in it. Events are locked per customer, so two arriving at once cannot both read a stale balance and both pay out.

The gamification work produced one decision we argued hard for. Every exchange in the study ran the same progress bar against deposits, and customers had long since learned what it wanted from them. We proposed a season-based pass instead, with a free and a premium track inside a reward hub shared across the products. Points earned anywhere count everywhere, which is what the portfolio argument looks like to a customer opening the app.

If each product had its own link to the loyalty system, every new product would need another integration. A reward rule spanning several products could force changes in several systems at once.

We designed one event contract for the whole portfolio. Each product would publish customer actions to an event queue. The loyalty system would read those events, apply whichever earning and reward rules were active, and publish the result to a reward queue. The product concerned would pick up the reward event and apply it to the customer account.

Those same events are what assembles the unified data layer. One contract does two jobs: it tells the loyalty system what a customer did, and it builds the record everything else reads from.

That keeps the boundary simple. A product reports what happened in the agreed format, and does not need to hold or understand the loyalty rules. Because every product speaks the same contract, the loyalty system needs no product-specific code to work out what a customer has earned. The rules can still test which product an event came from.

A new product joins the same way, by publishing to one queue and subscribing to the other. It still has that integration to build, and it can call the loyalty system's APIs for programme, customer and marketplace data where the interface needs them. What it does not do is negotiate a bespoke arrangement with the loyalty system, and existing products are not rewired to accommodate it. The reward rules stay where they are. An existing customer also keeps the history attached to their profile when they start using it, so the new product launches with something to reward on day one.

The queues decide how products reach the loyalty system. A second decision touched how the loyalty system should be built.

We considered two options. One application could hold the admin platform, event ingestion and reward calculation together. Or each part could run as a separate service with its own datastore. The single application is quicker to build and cheaper to run at low volume.

We recommended separate services, because the three parts differ in exposure and in load. The admin platform needs a controlled interface for NDAX staff. Event ingestion and reward calculation need no public interface at all, so they can sit inside the private network, and they were expected to carry most of the processing. As event volume grew, NDAX could add capacity to those two without growing the admin platform alongside them.

In the architecture document Aetsoft set out the single-application option and its lower starting cost as well. Separate services add complexity early. In return they keep event processing private and let NDAX scale the busiest parts on their own.