Verilay

The companies that verify your identity are now the ones losing it. Identity verification vendors sit between you and hundreds of apps. They see your passport, your selfie, and your address. Over the last two years, that position has made them one of fintech's most attractive targets. A few cases on the record: • AU10TIX (2024). 404 Media reported that administrator credentials for the ID verification vendor, whose clients have included TikTok, Uber, and X, had been exposed online for more than a year. • Coinbase (2025). Attackers bribed overseas support contractors to pull customer data, including ID images, then demanded $20 million. Coinbase refused and instead offered a $20 million reward for information on the attackers. • Discord (October 2025). About 70,000 users’ government ID photos were exposed through a third-party customer support vendor. • Sumsub (disclosed February 2026). An intruder entered through a third-party support ticketing platform and went unnoticed for about 18 months. Sumsub says ID images and biometrics were not accessed. • IDScan.net (September 2026). A dark web marketplace claimed more than 153 million driver’s license scans attributed to the vendor. A breach filing in Texas puts the number of affected people at about 13 million. In most cases, attackers didn’t break the verification engine itself. They came in through support staff, contractors, or exposed credentials: the human side of the operation. And in every case, the damage depended on what the company stored. A vendor that keeps millions of document images will always be worth attacking.

Why does your bank still have a scan of your passport from 2021? 🔎 Because the law tells it to. • Under EU anti-money laundering rules, banks, exchanges, and other regulated companies must keep customer due diligence records, including copies of identity documents, for five years after the business relationship ends. In the U.S., the Bank Secrecy Act sets a similar five-year retention period. • The rule exists so investigators can trace money after the fact. The side effect: every regulated company you’ve ever used is holding an archive of IDs and selfies, and each archive is a target for the next KYC data breach. The retention requirement is about proving a check happened. A verifiable record of the check can do that job.

Every Verilay credential passes through two separate roles before it reaches you. They do different jobs, and they see different things. ▶️ The verification provider checks the real world A registered provider does the actual verification: checks the document, confirms the degree with its source, verifies the employment record. The raw document goes to this provider. It doesn’t pass through Verilay. ▶️ The issuer turns the result into a credential The provider’s result goes to Verilay’s own issuer service. The issuer assembles and signs the credential. At this moment, the verified attributes are visible to Verilay’s infrastructure. We state this openly in our documentation because it’s true. Separating the roles also makes the provider accountable on its own: • Providers go through due diligence before they can issue a credential type • Every credential a provider issues becomes part of an auditable record • A provider shown to be negligent or malicious can be removed from the network • No credential type is designed to depend on a single provider What happens after issuance? A hash of the credential is anchored on-chain, with no attribute values. Every later use is a zero-knowledge proof generated on the holder’s device. From then on, the provider and the issuer are both out of the loop.

Proof of personhood answers one question: is there a unique human behind this account? It says nothing about whether that human finished a degree, held the job on their CV, or runs a real company. Hiring, lending, and onboarding depend on those facts. Verilay is built to verify them once a person has proven they’re real.

A credential can be perfectly genuine and still be presented by the wrong person. Someone borrows a friend’s degree. A relative applies with a sibling’s license. A contractor passes an interview with a colleague’s work history. The document is real in every case, but the person holding it isn’t the person it describes. This is the borrowed credential problem, and checking that a document is authentic doesn’t solve it. Our approach is the following: Every credential carries a binding grade that describes how strongly it is tied to its holder: • Identifier match — a trusted identifier from the holder’s verified identity matches the credential itself • Name match — the names correspond. Weaker evidence on its own • Issuer-confirmed — the issuer confirms the holder directly • Unbound — the credential is valid, and the holder link isn’t established A borrowed diploma would arrive with the borrower’s verified identity attached. In most cases, it can only reach a name match, and often not even that. A company sets the minimum grade it accepts in its verification policy. A policy that requires an identifier match won’t accept a credential whose link to the holder rests on a matching name.

Selective disclosure and zero-knowledge proofs both protect your data, but they work differently. • Selective disclosure: you share one field of a document and hide the rest. The site asking for your age sees your exact date of birth. • Zero-knowledge proof: you prove a fact about the field without sharing it. The site sees “over 18: true.” Your date of birth never leaves your device. Verilay uses the second approach. One proof per fact, and anyone sees only the fact.

Most verification starts with a company asking for documents. Verilay is designed to start with a company asking a question. That question is called a verification policy. Here’s how it works ↓ 1️⃣ The company gets verified first Before a business can publish a policy or receive proofs from candidates, it goes through KYB. Candidates know who is asking before they answer anything. 2️⃣ The company writes the policy A policy describes what the company needs to know, in terms of facts: • Which credential type it accepts, for example, a master’s degree or a confirmed employment period • What has to be true about it, for example, “issued by an accredited institution” or “age over 18” • How strongly the credential must be tied to the person presenting it. A policy can require an identifier match and refuse a plain name match. 3️⃣ The candidate’s device builds the answer The proof is generated locally, on the holder’s device, from credentials they already hold. The document behind the credential stays out of it. The proof shows that the policy is satisfied and reveals nothing beyond that. 4️⃣ The answer gets checked. The proof is verified against the policy. The company receives the result: the policy is met, or it isn’t. 5️⃣ The company keeps the answer. It ends up with the question it asked, the yes or no it received, and a proof it can check again later. The same credential can answer many different policies over time, from many different companies, with one proof per question.

When a company that verifies identities gets breached, attackers walk away with whatever it stored. In September, that meant passport scans, selfies, and transaction histories at Revolut, and IDScan claimed 153 million driver’s license scans. A business that checks a candidate through Verilay stores a different kind of record: the question it asked, the answer, and proof it can verify. Businesses receive a verifiable yes or no — never your documents. A breach on their side exposes the answer “over 18: yes.” The passport behind it is never stored in their database.

Verilay sits at the intersection of several adjacent markets. Worth being precise about what each one covers, because none of them cover the whole problem ↓ ▶️ Proof-of-personhood networks establish that you're a unique human. Useful, and silent on your education, employment history, a company's solvency, or counterparty trustworthiness. ▶️ Government digital identity provides high-trust official credentials — who you are, backed by a state. A rail, not a competitor. Verilay is designed to build on top of it: employment, qualification, and company trust, which government identity was never meant to address. ▶️ SSI and credential toolkits provide identity and attestation building blocks. Verilay uses primitives like these to build something more specific: a vertical credential catalog, a two-sided market, a review economy, and an economic layer for accountable trust production. ▶️ KYC and background-check vendors do strong real-world verification. Most are one-sided and vendor-controlled. Reusable verification already exists among them — reuse alone isn't a differentiator. ▶️ DataFlow Group and TrueProfile are the closest existing analog: regulator-mandated verification with holder-reusable results anchored on Ethereum. Verilay aims broader — two-sided verification, policy proofs, and a verified-employment review layer. ▶️ Parchment and Digitary run large education-document and credential exchange networks. They're strong in education records, but not built as cross-domain, two-sided verification and company-research networks. ▶️ Reputation and quest systems provide portable, often on-chain reputation, typically without the real-world provenance, regulation, or high-stakes verification required. ▶️ Employer-of-record and HR platforms run deep employer workflows. Verification and data mostly stay inside their own ecosystems, and company-side trust isn't symmetrical. Review platforms carry a large volume of workplace experience. Authorship and manipulation remain hard to prove at scale. Several of these categories are inputs Verilay builds on, not problems it replaces. The differentiation is the combination: two-sided verification where the company is also a subject, multi-credential coverage, holder binding that distinguishes genuine from yours, proofs held by the user rather than shared vendor-to-vendor, reviews gated by verified employment, and economic accountability for moderation and storage. Distribution competition with established, better-funded verification vendors remains real and unresolved.

Review platforms carry a structural problem: anyone can write one, and the reviewed company often has leverage over whether it stays up. Verilay's review economy ties the right to write a review to proof of verified employment, not to an account. • One structured review per verified employment period • Where possible, the proof comes from something the candidate controls — social-insurance or employment records — not something the employer signs off on • Employer-signed attestations remain a fallback path, but the design avoids giving the reviewed company a veto over whether the review exists at all A review dependent on the reviewed party's cooperation isn't independent. This keeps that dependency out of the loop.

Verification systems put a lot of weight on trusting the provider that did the checking. A registered provider can be negligent, or wrong, or compromised — and a credential built on that check inherits the problem. Verilay's documentation names this risk directly. What's designed to happen when it occurs? ▪️ Provider due diligence up front. Before a provider is registered to issue a given credential type, it goes through a due diligence process. The bar for entry includes whether the provider's real-world verification practice can be trusted. ▪️ A public history of what each provider has attested to. Every credential a provider issues becomes part of an auditable record. A provider's track record — credentials that don't hold up, patterns of bad attestations — stays visible. ▪️ The ability to remove a provider. A provider shown to be negligent or malicious can be removed from the network. Failing the trust it's been given costs a provider its ability to keep issuing credentials. ▪️ More than one path per credential type. No credential type depends on a single provider. A correlated failure at one provider — a batch of bad checks, a systemic issue — doesn't expose the whole system through one point. A provider that looks legitimate and fails in a correlated way remains a real residual risk. These mechanisms make failure visible, accountable, and recoverable rather than invisible and permanent.

Verification scams don't only run one direction. A fake company can look just as convincing to a candidate as a fake candidate looks to a recruiter. We treat that as a symmetric problem: • Companies go through KYB before they can publish a verification policy or receive candidate proofs • A research pipeline is designed to cross-check corporate registries, sanctions data, financial records, and court records A candidate accepting an offer gets the same kind of check a company runs on them. Fake employers face the same bar as fake employees.

A name match sounds like proof. On its own, it isn't. Two people can share a name. A name can change after marriage. A name can transliterate differently across two documents from two countries. None of that means fraud. It means "same name" doesn't reliably mean "same person." Verilay treats a name match as weaker evidence than an identifier match. An identifier match ties a trusted number from your verified identity directly to the credential. A name match ties two strings of text that happen to look the same. The binding grade stays visible. A verification policy can require identifier-level proof instead of accepting a matching name. Weaker evidence isn't hidden here. It's labeled as weaker.

"This diploma is real" and "this diploma is yours" — two different claims. Most systems prove only the first. Verilay grades the link between a credential and its holder into four levels: • Identifier match — a trusted identifier from your verified identity matches the credential itself • Name match — names correspond, weaker evidence on its own • Issuer-confirmed — the issuer confirms you directly • Unbound — the credential is valid, but the holder link isn't established A verification policy decides which grade it's willing to accept.

A thousand reviews mean nothing if you can't prove who wrote them. Most reputation systems accumulate badges, points, and quest completions — volume without provenance. Verilay's review layer starts differently: ▪️ A review only exists if gated by a verified employment credential ▪️ Proof the reviewer actually worked there, for the period they're reviewing ▪️ Fewer reviews than a quest platform generates in a day The number that means something when the stakes are a hire, a loan, or a lease.

What happens when a credential gets issued? 🔍 A registered provider does the real-world verification — checking a document, confirming a degree, attesting to employment. 📥 The result passes to Verilay's own issuer service, which assembles the credential and signs it. At that moment, the verified attributes — the actual values, not a yes/no — are visible to Verilay's infrastructure. This is a stated design property, not an accident: • Verilay operates its own issuer rather than delegating that role to a third party • New document types, jurisdictions, and verification sources plug into one issuance pipeline instead of a dozen incompatible ones • The tradeoff is direct — at the moment a credential is created, the data behind it passes through systems Verilay operates

Every credential in Verilay's design moves through the same six-stage lifecycle, regardless of what fact it represents. 1️⃣ Verification A registered provider performs the real-world check: identity/KYC, education verification, employment attestation, registry lookup, or a financial-data check. 2️⃣ Issuance The verified attributes pass to Verilay's own issuer service, which assembles and signs the credential. In the current design, Verilay's infrastructure can see verified attributes at this point – a property of how issuance works. 3️⃣ Anchoring The chain stores credential metadata and a cryptographic commitment (not the raw document or attribute values). A fingerprint of the fact lives on-chain, not the fact itself. 4️⃣ Presentation When a verifier requests a policy check, the holder's device generates a zero-knowledge proof locally. The proof gets checked against the policy, the provider registry, and the credential's current validity and revocation status. 5️⃣ Reuse The same credential is designed to satisfy future policy requests without returning to the original issuer each time. Verify once, present the proof as many times as needed. 6️⃣ Revocation, expiry, or deletion Every credential reaches one of four uniform states: valid, expired, revoked, or voided. A verifier reading the credential's status sees one of these outcomes, regardless of the credential type. A diploma and a criminal-record check are different facts, held to different standards. They move through identical machinery: the same verification step, issuance boundary, anchoring, proof mechanism, reuse model, and lifecycle states. That consistency lets the credential catalog grow without the system growing more complicated alongside it.