An Exchange Verifies the Same Person Every Time Something Changes
No exchange has deployed anything described here. Nothing on this page is legal advice.
The vertical where the same proof is built most often
A licensed crypto business verifies a customer at signup. Then it verifies them again.
Again when the licence conditions change and the regulator's expectations move. Again when the customer's jurisdiction changes. Again when the internal risk model is revised and a cohort is re-examined. Again when a dormant account wakes up. Again when the business enters a new market under a different supervisor.
Each round is the same customer, the same document, the same photograph, and the same cost. The customer, who has done this before at this exact company, is asked to do it again from the beginning.
Why this vertical rather than another
Three properties stack here in a way they do not elsewhere.
The overlap between platforms is unusually high. People who use one exchange typically use several. That is not true of banks in the same way, and it means the population arriving at any given platform has, in large part, already been verified somewhere by somebody applying comparable standards.
Friction is directly and visibly expensive. Onboarding in this sector competes against alternatives that are one tap away, and every additional step in a document capture is a place a signup ends. The finance team can see the shape of it even without a vendor's chart.
And the rules move. A sector whose supervisory expectations are still being written is a sector where re-verification is a recurring event rather than an edge case. Every rule change turns a completed cost into a repeated one.
The result is a market where the proof already exists, several times over, and cannot travel.
What Türkiye did that makes this concrete
Turkish regulation now names the method for remotely identifying foreign nationals: a chip-bearing passport, read and matched against the printed details. Crypto-asset service providers were brought inside that remote-onboarding regime at the same time.
That is unusual and useful, because it converts an argument into a specification. A vendor no longer has to persuade anyone that its approach is equivalent to something; the requirement names the technique. The rule itself is MASAK Tebliğ 32, and the two places any claim about it has to stop are that it covers foreign nationals rather than the whole market, and that our own chip verification has been validated against synthetic certificates rather than real passports in production.
What we are not, and why it is commercially relevant
We are not a virtual asset service provider and not a crypto-asset service provider under any definition. We do not exchange assets, transfer them for customers, or hold custody of anything.
That is worth stating for three reasons a counterparty cares about.
We do not compete with you. An identity vendor that also runs an exchange is a different proposition, and the question of what it learns about your customers has a different answer.
We do not hold your customers' assets, so a failure of ours is not a loss of funds.
And we are not on any national register of licensed crypto businesses, because we have not applied to any and the activity does not require it. If you need a counterparty who is on such a register, that is not us and no amount of engineering changes it.
What reuse actually compresses, stated narrowly
The identity leg, and nothing else.
Establishing who somebody is, which is the expensive, abandonment-prone, repeatedly-rebuilt part, is what a portable credential compresses. It does not touch sanctions and watchlist screening, which we do not perform at all. It does not touch transaction monitoring. It does not touch the record-keeping obligations that attach to your licence.
And accepting a reused credential does not discharge your own obligation to know your customer. If your supervisor holds you responsible, it holds you responsible after you accept somebody else's check. What changes is what satisfying that obligation costs you, not whose obligation it is.
Any vendor telling an exchange otherwise is describing a saving that will not survive an examination.
The honest state of it for an exchange evaluating today
There is no reference deployment, no case study and no logo, and there will not be one on this page before there is one in reality.
The trust registry that decides which issuers are acceptable is operated by us alone, which is a real dependency rather than a footnote, and it is the one to interrogate hardest if you are considering building on this.
The roadmap position is a first deployment with an exchange, and the gates in front of it are the three named above rather than a date. We would rather hand you the gates than a quarter.
What an exchange should ask any identity vendor
"What share of my onboardings are people who have verified elsewhere in the last year?" Nobody can answer this precisely, including us, and how a vendor handles a question they cannot answer tells you how they will handle the rest.
"Which of my obligations does this remove?" The correct answer is none. It changes what they cost.
"Do you screen, and against whose data?" If a vendor bundles identity and screening without naming the feed, ask separately about each.
"Who else can operate the infrastructure if you stop?" For us, today, nobody, and the honest version of that answer is a plan rather than a principle.
Where this leaves a decision
If you need a vendor with exchange deployments behind them, we do not have one and you should weight that heavily.