What the everyday tells you.
A programme that is opened twice a year tells you what was bought. A programme that sits in an app people open on a Tuesday tells you what they like, where they go, who they go with and what they leave unused.
That is the difference we build on. The signals come from ordinary use, they come back to you as data and dashboards, and they are what the personalisation runs on — for the member, and for the campaigns you run.
Your programme, live, inside BLACKBOOK.
A portal for your team: who is using the programme this week, in which cities, on which benefits; what is being booked and what is being ignored; the liability sitting against benefits that have been granted but not taken.
It is the same view we run on, not an export sent monthly.
The signals, as data.
Where the card is used and where it goes quiet. Which benefits are taken up, by whom, and how often. What is booked, in which city, at which times, with how many people. What a campaign moved, and what it did not.
Delivered into the portal, and into your own systems through the API.
The right thing, at the moment it is useful.
The AI reads live intent rather than a segment set last quarter: the city they are in today, the table they book every second Thursday, the benefit that runs out this month, the trip already in the wallet.
The member sees something worth acting on. You see the take-up move.
Consent, held as a record.
Members are anonymous to us until they say otherwise: we hold an encrypted reference, and identity opens only with the member’s permission. Permissions are recorded as timestamped events, so what a member allowed, and when, can be evidenced. Browsing history is not a feed we take.
How identity, tenancy and permission work is set out in full below.
Signals are consented and event-based. Nothing here comes from browsing history.
- MembersWho joined, who is active this week, who has gone quiet, and what moved them.
- BenefitsGranted, surfaced, used and expired — with the liability against each.
- BookingsHotels, tables, cars, experiences and retail, by city and by week.
- CurrencyPoints and miles earned, spent and exchanged, and where they came from.
- CampaignsWhat was sent, what was opened, what was booked, and what it cost per booking.
Members are anonymous to us until they say otherwise.
Every member on BLACKBOOK is held as an encrypted reference. We see what happens in the app, so the product can work for them; we do not see who they are unless they give us permission to.
Each partner runs in its own tenancy, and sees what its role needs and nothing more. Every permission is recorded, can be seen by the member and can be taken back.
Who sees what
Anonymous by default
A member is an encrypted reference, not a name. Their name, contact details and documents are held encrypted and apart from what they do in the app, and are opened only for a purpose the member has allowed.
Identity, one permission at a time
A member reveals who they are to a partner, or to us, one permission at a time: the hotel desk at check-in, the car-hire counter, our own team when they ask for help. Each reveal is scoped to its purpose and ends with it.
A tenancy for every partner
Each partner runs in its own tenancy, with its own data, its own keys and, where it needs one, its own region. One partner’s data is never visible to another, and no model is trained across partners.
Encrypted, in transit and at rest
Data is encrypted as it moves and where it is stored, with keys held per tenancy. Access is limited to the people and systems that need it, and every access is logged.
Permissioned, logged, asked again
Every permission and every consent is recorded as a timestamped event. A member can see what they have agreed to and change it at any time, and we ask again whenever the purpose changes.
What we never do
We do not sell member data and we do not buy it. Browsing history is not a feed we take, and a card number never moves through our systems.
Signals, where a name is not needed
Where a partner does not need a member’s details, it gets signals instead: an opportunity to offer something, a benefit going unused, a group of members in town. What a member does elsewhere in the app stays with us.
Retention with an end date
Data is kept for as long as its purpose lasts and no longer. A partner that leaves takes its data with it, and a member who leaves can have theirs removed.
Consent is enforced
A permission is checked every time something is done under it. If it has been withdrawn or has run out, the action does not happen.
Private until a booking needs a name.
What a member searches for, plans and saves is encrypted and held against their reference, not their identity. Personal details pass only at the point a booking needs them, only to the party that needs them, and only with the member’s permission. Each step is a gate: the permission is checked and the event is logged.
Encrypted, and tied to a reference.
AnonymousSaved to the trip, still under the reference.
AnonymousThe supplier holds the room or the table against a reference.
Reference onlyThe fields the booking needs pass to that supplier, with permission.
Only what is neededThe member reveals who they are at the desk, if they choose to.
With permissionAt every gate: the permission is checked, the event is logged with its time, and the member can see it.
GDPR as the standard, wherever a partner operates.
We hold ourselves, and the partners who run on BLACKBOOK, to the GDPR standard in every market, alongside the law where each partner operates: at home, the DIFC Data Protection Law and the UAE’s Personal Data Protection Law.
- Lawful and consentedA clear basis for every use of data, and consent that is specific, recorded and as easy to withdraw as it was to give.
- Purpose and minimumData is collected for a stated purpose and no more of it is taken than that purpose needs.
- The member’s rightsTo see what is held, correct it, move it, object to a use of it, and have it deleted.
- Roles, written downWho controls and who processes each piece of data is set out in the agreement with every partner.
- ResidencyData held in the region the partner chooses, in its own tenancy.
- If something goes wrongIncidents are reported to the partner and, where the law requires it, to the regulator and to the members affected, within the time the law sets.
Insight from the everyday, on the member’s terms.
Behavioural insight needs everyday use: an app opened twice a year has very little to learn from. BLACKBOOK is used every day, and members share that use when they can see what it does for them, and when they can switch it off or narrow it at any time.
Everyday use is the signal
The coffee, the court, the table on Thursday and the trip in October. The pattern comes from an ordinary week.
On, off or limited
Location, spending, calendar and preferences are separate permissions. A member can turn any of them off or limit it, and the app keeps working.
Useful, or not used
A signal is used to put something helpful in front of the member. If it does not make the app more useful to them, we do not collect it.
Our own rails, end to end.
An agent can only act for a member if it knows who they are, what they have allowed, what they hold and how to pay. In BLACKBOOK those sit on one system we build and run ourselves: identity and consent, the wallet, supply, and payment, with every action logged against the permission it was taken under.
That closed loop is why BLACKBOOK can offer agentic commerce from search to settlement sooner than platforms that have to stitch it together from other people’s systems.
The member, their permissions and the limits on them, checked on every action.
Cards, points, miles and memberships the agent can pay with, inside the member’s limits.
Stays, flights, tables and experiences the agent can search, hold and book.
One basket settled once, and every step written to the log.
Permission to act, in both directions.
- OncePermission given, then acted on
- Every actionRecorded as a timestamped event
- Both waysYour supply, reachable by other agents
The member gives permission once, and the app can act for them: hold the table, move the booking, pay for it, keep the itinerary current when the flight moves. Every permission and every consent is recorded as a timestamped event, so what was agreed to can be evidenced later.
It runs the other way as well. Through our connectors, a partner’s rooms, tables, seats and benefits can be reached by other agents and assistants, with identity, consent and payment attached to the request — so the supply can be found and bought where the customer is already asking, rather than only on the partner’s own site.
This is what we are building, on the identity and permission layer set out above.
Every line on the right carries the consent it was acted under. Nothing happens without one.
See it running on your programme, with your benefits and your rules.