Privacy notice

This is a draft prepared for review. It has been written from the IBX code and product specification, not from instructions by a lawyer, and it is not legal advice. Every item in [SQUARE BRACKETS] is a fact the owner must supply before this is published.

IBX is a members-only business-introduction network. Members post a photograph of their own business card, exchange cards with people they meet, post asks, and introduce each other's asks by hand. This notice explains what we do with personal data, why, for how long, who else sees it, and what you can ask us to do about it.

We have tried to describe the system as it actually is, including the parts that are awkward. Where we keep something longer than you might expect, we say so and say why.

1. Who we are

"Controller" means the company that decides why and how personal data is used, and is answerable for it. For everything that happens inside IBX, that is us.

Membership dues are invoiced by a selling entity for your corridor. That entity may not be the same company as the controller named above; it is named on your invoice and listed at [BILLING ENTITIES PAGE OR CONTACT].

Our surfaces are the mobile app, the member website and public site at joinibx.com, and a staff-only back office at ibx.developeroffice.com.

2. The short version

• You post your own card. There are no public profiles, no bios, no follower counts, no likes and no way to search other members' cards.
• The phone number and email address printed on a card are encrypted and stay hidden. They are revealed only to the two people on either side of an accepted introduction, and every single reveal is written to an audit record.
• We never collect, infer or store your age, gender, ethnicity, religion or any similar attribute. The only grouping we keep is the month you joined.
• Card images, post text and some flag and message text are sent to Anthropic in the United States so that a Claude model can read, check, translate or screen them. The decision records are kept for 24 months.
• We also use Cloudflare (hosting and card-image storage), Google Firebase Cloud Messaging (push notifications to Android devices), Sentry (crash and error reports, stripped of personal data) and a mail server running Postal (invoices, statements, application emails and sign-in codes).
• You can delete your account yourself. It completes within 30 days. But introductions and accepts that already happened are a shared record between two people, so they are never rewritten — your place in them becomes an anonymous marker. Our security audit record also keeps your original account identifier, the IP address you acted from, and what staff did. Section 9 explains this honestly.

3. What we collect, and why

3.1 Your own card

When you apply, and whenever you add or change a card, we hold:

• The photograph of the card, front and, if you add one, back. The cleaned-up photo is the real photo. We never generate a replacement image, because a generated card could silently change a contact detail. The app also draws a neat typeset version of the card from the fields you confirmed; the real photo is always one tap away.
• The business fields printed on it: name, company, role, sector and category, country, city and website. You confirm each field by tapping it before the card goes live. Once confirmed, these fields are frozen — changing them creates a new version of the card rather than editing the old one.
• The phone number and email address printed on it. These are encrypted at rest with a key held outside the database, and we store a one-way fingerprint of each one so we can detect the same number or address being used on two different accounts.
• Technical fingerprints of the image (a cryptographic hash and a perceptual hash), so that the same card image cannot be used to open a second account.
• One line you write about what you are looking for or can introduce.

3.2 Your membership account

• Your sign-in destination (today, an email address). We do not store it in readable form: we keep an encrypted copy plus a one-way index so we can look you up when you ask for a sign-in code.
• Your country, your language, your time zone if you set one, and your notification preferences.
• The month you joined. This is the only way we group members. There is no age, no date of birth, no gender, no photograph of you, and no demographic field anywhere in the system.
• An attestation that you are 18 or over: a tick box and a timestamp. We do not collect your date of birth, so we hold no way to check it.
• An attestation at your first card scan that the card is your own, that its business fields will be shown to members you exchange with, and that the contact fields stay hidden until an accept. Again, a timestamp.
• Sessions and devices: session records, single-use refresh tokens, and the push token of each device you sign in on.

3.3 What you do in the network

• Exchanges — which cards are in your wallet, who with, when, whether you met the person in person, and whether either side removed the card.
• Asks and offers you post, their structured fields, and their translations.
• Introductions — every hop of every chain: who passed what to whom, when, whether they marked it "I know them", any note they wrote, and when the hop clock runs out.
• Accepts — which introduction the asker accepted, and the credit that followed.
• Thank-you notes, replies, gift notes and the one pre-accept question, including the text you wrote.
• Flags and disputes you raise, and appeals you make.
• Verification records — whether a website, a company registry or an ownership code checked out, and how many members met you in person. We store the registry provider's reference, never registry documents.
• Derived signals we work out about behaviour, such as the same card image appearing on two accounts, or two members accepting each other repeatedly. These are private, used for routing and for fraud review, and never shown to other members.

3.4 Money

Invoices, the amounts, the currency, the tax contained in them, payments recorded against them, grant records, gift records and your annual statement. Dues are annual and priced by country band; a grant is recorded as a party that paid part or all of an invoice, and the full displayed price always stays on the invoice.

We do not store your billing address or any card or bank details. Dues are currently settled by bank transfer against the invoice number, and a member of staff records that the money arrived.

3.5 Technical and security data

• Audit records of every reveal of a contact detail, every staff action in the back office, and sensitive member actions such as requesting deletion. Each audit record can carry the actor's account identifier, the IP address, the browser or app user agent, a request identifier and a before-and-after difference of what changed.
• Rate-limiting counters. For logged-out visitors these are keyed by a one-way hash of the IP address and a time bucket. The IP address itself is not stored for public rate limiting.
• Error reports — see section 6.

3.6 Cards of people who are not members

This is the part of IBX that needs the most care, so it has its own section. See section 5.

4. Why we are allowed to do this (lawful bases)

Under the GDPR and similar laws we need a lawful basis for each purpose. Here is ours, purpose by purpose. "Contract" means Article 6(1)(b) — we need to do it to give you the membership you are paying for. "Legitimate interests" means Article 6(1)(f) — we have a real interest, the processing is necessary for it, and we have weighed it against your rights; where we rely on it we name the balance below.

We do not ask for your consent as the basis for the core service, because the service is something you are paying for and consent you could not realistically refuse would not be real consent. The only true consents in the product are the ones your own device asks you for — camera access and push notifications — and you can withdraw those in your device settings at any time. Nothing else we do stops working if you do.

We never process special category data (health, beliefs, biometrics, sexual orientation, trade union membership, and so on). A business card does not normally contain any, and nothing in IBX asks for it or infers it. If you print such information on your own card, you are publishing it yourself; please do not.

5. Cards and contacts of people who are not members

This is the sharpest privacy question in IBX, so we will be direct about it.

5.1 What IBX does not do

Your wallet does not contain photographs you took of other people's cards. When you and another member exchange, your wallet holds a link to that member's own card, the one they posted and confirmed themselves. If they change or delete it, what you see changes with it. There is no address book of strangers inside IBX, and no member can search other members' cards at all.

5.2 What IBX does do, and why it is third-party data

Two things in the product do involve a person who never signed up.

A card you were handed at a meeting. When you meet someone and scan the card they gave you, the app uploads that photograph so we can work out which member's card it is — by comparing it against the cards members have posted. If it matches, we create an exchange request, which the other member must accept. If it matches nobody, nothing happens: the person is not a member, and there is nothing to exchange with.

That photograph is a photograph of another person's personal data, taken and uploaded without that person being asked by us. It is held as a staged upload and:

• it is never shown to any other member, and never placed on a public address;
• it is deleted automatically 7 days after upload if it was not used to create one of your own card versions, and the stored image is deleted with it;
• an upload link that is never used is rejected after 15 minutes;
• while it exists, the cryptographic hash of the image may be compared against other cards and uploads, to detect the same card being used to open two accounts.

An invitation that carries an ask. A member may invite a specific person to join by sending them a message carrying a real ask or offer — never a bare link. To do that we hold that person's contact detail, encrypted, with a one-way fingerprint. The invitation says who sent it and why, and carries a one-tap way to say no. If the person does not join, the contact detail is deleted after 30 days.

5.3 Our position: we are the controller

For both of these, IBX is the controller. We decide why the photograph is uploaded (to identify a member), how long it is kept (7 days), what is derived from it (hashes used to detect duplicate accounts) and what never happens to it (it is never shown to another member). Those are controller decisions, and we do not get to call ourselves a processor acting on a member's instructions, because the member cannot instruct us to change any of them.

The member may *also* be a controller of the same card in their own records — their own notes, their own address book, their own CRM — but that is their processing, outside IBX, and this notice does not cover it. We do not consider this joint control, because the member and IBX do not jointly determine any of the purposes or means described above.

5.4 The notice problem, stated plainly

Article 14 of the GDPR says that when we obtain personal data about someone from a third party, we should tell that person. For a card handed over at a meeting, we normally cannot: we hold an image for a few days, we have not read a contact detail out of it, and we have no reliable way to reach the person — the whole point is that we do not yet know who they are.

We rely on Article 14(5)(b): giving individual notice would take disproportionate effort relative to a few days of storage of an image the person physically handed to someone for exactly this purpose. Instead we do what that provision asks: we publish this notice, we keep the data minimal and short-lived, and we restrict who can see it to nobody.

For an invitation, the position is the opposite and better: we *can* reach the person, so we do. The invitation itself is the Article 14 notice — it names the sender, says why, links here, and offers one tap to be removed.

Our honest view: the invitation path is defensible. The handed-card path is defensible but not beyond argument, and it is listed as an open question for our lawyer in LEGAL-REVIEW-NOTES.md.

5.5 If a card of yours is in IBX and you are not a member

Write to [PRIVACY EMAIL]. Tell us the name and company printed on the card and, if you can, attach a photograph of it. We can search by image fingerprint and by a one-way fingerprint of a phone number or email address. We will tell you what we hold, delete it, and stop any invitation addressed to you. We will answer within one month.

We may not be able to tell you *which member* uploaded it, because that would disclose their personal data too; we will decide that case by case and explain our reasoning to you.

6. Who else sees your data

We do not sell personal data, we do not share it for advertising, and no analytics tool receives card text or contact fields. These are the companies that process data on our behalf.

Our own staff see data in the back office according to their role: a reviewer sees applications and flags, a billing administrator sees invoices. No member of staff can see any member's encrypted contact details at all — the back office has no access to that table. Every staff action is recorded with a before-and-after difference.

We will also disclose data where the law requires it — a valid court order, a tax investigation, a regulator — and where we need to defend a legal claim. If we are ever asked for member data by an authority, we will tell the member unless we are forbidden from doing so.

7. Sending data outside your country

Our database is physically in the European Union (primary in Finland, standby in Germany), and card images are stored in a bucket created with European Union jurisdiction. For members in the EU that is the strictest arrangement; for members elsewhere it is also where their data sits today.

Four of our processors are in the United States: Anthropic, Google, Sentry and Cloudflare's parent company. Encrypted database backups are stored in a United States region.

For each of those transfers we rely on:

• the Standard Contractual Clauses adopted by the European Commission, as part of our contract with each company; and
• where the company is certified, the EU–US Data Privacy Framework [CONFIRM WHICH OF ANTHROPIC, GOOGLE, SENTRY, CLOUDFLARE AND BACKBLAZE ARE CERTIFIED]; and
• a written assessment of the risk of each transfer [TRANSFER IMPACT ASSESSMENT — TO BE COMPLETED], plus the technical measures described in this notice: contact details are encrypted, card text and contact fields never reach the error tracker, and model decision records are scrubbed of contact values before they are stored.

The backup conflict, stated honestly. Our product promises that European members' data stays in Europe. Our encrypted database backups currently sit in a United States region. The backups are encrypted, and the key that protects members' contact details is not in them — but this is still a gap between what we promise and what we do. It is recorded as a blocking item in LEGAL-REVIEW-NOTES.md, and it must be closed — by moving the backup target to a European region, or by narrowing the promise — before this notice is published to European members.

Before we open a corridor to a new country we carry out a review against the data protection law at each end, including the GDPR, Sri Lanka's PDPA and India's DPDP Act.

8. How long we keep things

These periods come from the running code, not from an intention.

9. Deleting your account — and the limits of it

You can delete your account yourself, from the app or from the member website. You confirm with a one-time code sent to your own sign-in address, so somebody who steals a signed-in session cannot delete your account.

How it runs. We hold the request for 14 days, during which you can cancel it with one tap and nothing has happened. On day 14 it executes. Deletion is complete within 30 days of your request — the 14-day window leaves room for a failed run to be retried and still meet that deadline. Card images are deleted from storage by a separate job that drains a queue of image keys, and deletion is not complete until that has run.

What is deleted:

• your cards, their photographs and the details printed on them;
• your contact details, and the contact details you unlocked;
• your wallet: every exchange, on both sides;
• thank-you messages, replies, gift notes and pre-accept questions you wrote;
• your notifications, devices, sign-in details and every signed-in session;
• your verification records, your gift registry and your cached standing;
• the behaviour signals we derived about you.

Open asks you posted are closed. Introductions that were waiting on you are dismissed.

What stays, and why. We cannot honestly promise that nothing remains, so we will not.

1. Introductions and accepts that already happened. An introduction is a record two other people share: the person who passed it on, and the person who accepted it. Rewriting it would rewrite their history, not just yours. Your place in those chains is replaced by a fresh anonymous marker that carries no country, no cohort and no attestations. The chains keep their shape; the person is gone from them.
2. The credit those accepts earned, against the same anonymous marker.
3. Invoices, payments and gift records, against the same marker, for as long as tax law requires.
4. The text of asks you posted stays as context for the chains that hung off it. Your name, your card, your notes and your message bodies do not.
5. Our security audit record keeps the rows written while your account existed — including your original account identifier, the IP address you acted from, and, for staff actions concerning you, the before-and-after of what changed. Those rows are what let us prove who read a contact detail and what a member of staff did. They are not purged or pseudonymised today, and they are the one place where the anonymous marker could, in principle, be linked back to you by someone with access to our database. We think keeping them is justified for security and fraud investigation, but we are not going to describe the result as complete erasure, because it is not. Choosing a retention period or pseudonymising these rows is a recorded open item.

If you want the stronger outcome — an erasure that reaches the audit record — write to [PRIVACY EMAIL] and say so. We will consider it on its merits and tell you our reasoning and, if we refuse, your right to complain.

10. Your rights

If you are in the European Union, the United Kingdom, or another country with similar law, you have the rights below. We answer within one month. We do not charge for it.

To use any of these, write to [PRIVACY EMAIL] from the address you sign in with, or ask from inside the app. If we cannot be sure it is you, we will ask you to confirm with a one-time code rather than ask you for documents.

If you are not a member and a card or contact detail of yours is in IBX, see section 5.5. You have the same rights.

11. Decisions made with AI, and where a person comes in

A Claude model from Anthropic runs at twelve points in the product: reading a card, classifying an ask, checking an ask against the community rules, suggesting who to introduce it to, translating, screening for fraud, triaging a flag, writing the weekly digest, coaching a returning member, reviewing an application, drafting the trust line shown before an accept, and screening a thank-you message.

Nothing is decided by the model alone. We mean that structurally, not as a reassurance:

• Reading your card. The model proposes field values. You confirm each one by tapping it. Nothing goes on your card that you did not confirm.
• Low confidence always escalates. Every decision carries a confidence score. Below 0.7 the work is re-run on a stronger model. If it is still below 0.7, the item goes into a human review queue and you are told it is being checked.
• Applications. The item for a human reviewer is created before any model runs, so an AI outage cannot swallow your application. The model's opinion is advice attached to that item. A person approves or declines.
• Asks. A vague or borderline ask is returned to you with the reason and a suggested rewrite, and you can edit and resubmit it. A refusal names the rule it broke.
• Enforcement. Warnings, limits, suspensions and removals are decided by staff. Every flag lands in a human queue with a 72-hour service target.
• Routing suggestions are suggestions shown to a member, who chooses whom to introduce.

Because of this, we do not believe anything in IBX is a decision "based solely on automated processing" that produces legal effects or similarly significantly affects you, in the sense of Article 22. But we are not going to hide behind that: every automated refusal or enforcement step is appealable to a person inside the app, you are told when a decision was automated, and you are told the reason. That is what Article 22 would require of us if it applied, and we do it anyway.

We log every model decision — the touchpoint, prompt version, model, confidence, a fingerprint of the input and a redacted copy of the output — for 24 months, so that a decision can be explained to you and reproduced. Contact values are scrubbed out of that log before it is written, at a single gate that every touchpoint passes through, so a model that echoes a phone number back in prose cannot put it there.

We do not use your data to train AI models, and our agreement with Anthropic is that it is not used to train theirs [CONFIRM AGAINST THE SIGNED ANTHROPIC COMMERCIAL TERMS].

12. How we keep it safe

• Contact details are encrypted with a separate key for each record, which is itself wrapped by a master key held outside the database. Staff have no access to that table at all, and the database itself refuses to hand a contact detail to a member — it can only be read through a function that checks the reader is a party to an accept and writes an audit record in the same breath.
• Card images are never on a public address. They are stored under opaque keys and served only through signed links that expire in two minutes, and never for longer than five.
• The database enforces the rules, not only the app. Row-level security is switched on and forced on every table, so a bug in the API cannot show one member another member's data. Introductions, accepts, credit records and the audit record are append-only: the database refuses to change or delete them.
• Caching that could cross between members is switched off, deliberately, on the database connection pool.
• Sign-in is a one-time code, not a password. Staff passwords are hashed with 600,000 rounds of PBKDF2 plus a secret pepper. Sessions are short, refresh tokens are single-use, and re-using one revokes the whole session.
• The site enforces HTTPS, with a minimum of TLS 1.2.
• No analytics tool, anywhere, receives card text or contact fields.

No system is perfectly safe. If a breach ever puts you at risk, we will tell the relevant supervisory authority within 72 hours of becoming aware of it, and we will tell you.

13. Children

IBX is a service for people in business, and you must be 18 or over to join. You attest to that with a tick box when you apply. We deliberately collect no date of birth and no age, which is a privacy choice with a consequence we should say out loud: we cannot verify your age beyond that attestation. If we learn that someone under 18 has joined, we will remove the account.

14. Cookies and tracking

The public site and the member website use no advertising cookies, no tracking pixels and no third-party analytics. The member website sets a session cookie so that you stay signed in; it is marked HttpOnly, Secure and SameSite, and scoped to the member area only. That is the whole list.

The app stores your session on your device. Nothing in IBX follows you to other websites.

15. Changes to this notice

If we change something that matters — a new processor, a new purpose, a longer retention period — we will tell members by push notification or email before it takes effect, and we will keep the previous version available on request. The version and date at the foot of this page is the authoritative one.

16. Complaints

Write to us first at [PRIVACY EMAIL]. We would rather fix it than argue about it.

If we do not resolve it, you can complain to a data protection supervisory authority. Ours is [LEAD SUPERVISORY AUTHORITY AND ITS CONTACT]. You can also complain to the authority in the country where you live or work, or go to court.

IBX — International Business Exchange

Operated by [LEGAL ENTITY NAME], [REGISTERED ADDRESS].

Version: privacy-2026-10-27-draft-1

Last updated: 27 October 2026