39 points rosasalberto 4 hours ago 39 comments
Being identical twins, we’ve spent our whole lives dealing with identity confusion, so it is a bit of irony that we ended up building a company to solve it for the internet.
Growing up in Barcelona, we spent years working on products where identity issues were a massive pain. We eventually realized that for most engineering teams, "global identity" is a fiction—in reality it is a fragmented mess. You end up stitching together one provider for US driver's licenses, another for NFC chip extraction in Europe, a third for AML screening, a fourth for government database validation in Brazil, a fifth for liveness detection on low-end Android devices, and yet another for biometric authentication and age estimation. Orchestrating these into a cohesive flow while adapting to localized regulations like GDPR or CCPA is a nightmare that makes no sense for most teams to be working on.
When we looked at the existing "enterprise" solutions, we were baffled. Most require a three-week sales cycle just to see a single page of documentation. Pricing is hidden behind "Contact Us" buttons, and the products themselves are often bloated legacy systems with high latency and abysmal accuracy.
We also noticed a recurring pattern: these tools are frequently optimized only for the latest iOS hardware, performing poorly on the mid-range or older Android devices that make up a huge percentage of the market. This results in a "leaky" funnel where legitimate users drop off due to technical friction and fraud goes undetected because data points are spread across disparate systems. Also, these systems are expensive, often requiring massive annual commits that price out early-stage startups.
We wanted to build a system that is accessible to everyone—a tool that works like Stripe for identity, where you can get a sandbox key in thirty seconds and start running real verifications with world-class UX and transparent pricing.
To solve this, we took the "delusional" path of full vertical integration. Rather than just wrapping existing APIs, we built our own ID verification and biometric AI models—from classification and fraud detection to OCR models for almost every language. This vertical integration is fundamental to how we handle user data. Because we own the entire stack, we control the flow of sensitive information from end-to-end. Your users' data doesn't get bounced around through a chain of third-party black boxes or regional middle-men. This allows us to provide a level of security and privacy that is impossible when you are just an orchestration layer for other people's APIs.
We believe that identity verification is one of the most critical problems on the internet, and must be solved correctly and ethically. Many people are rightfully skeptical, especially given recent news about projects that have turned identity into a tool for mass data collection or surveillance. We don’t do anything of the sort, but we also don’t want to be coerced in the future, so we facilitate data minimization on the customer side. Instead of a business asking for a full ID scan, we allow them to simply verify a specific attribute—like "is this person over 18?"—without ever seeing the document itself. Our goal is to move the industry away from data hoarding and toward zero knowledge, or at least minimal knowledge, verification.
The result of our all-in-one approach is a platform that increases onboarding rates while lowering identity costs. We’ve focused on building a high-confidence automated loop that reduces the need for manual review by up to 90%, catching sophisticated deepfakes and spoofing attempts that standard vision models miss. Our SDK is optimized for low bandwidth connections, ensuring it works on spotty 3G networks where legacy providers usually fail.
We are fully live, and you can jump into the dashboard at https://business.didit.me to see the workflow orchestration immediately. Our pricing is transparent and success-based; we don’t believe in hiding costs behind a sales call.
We’re here all day to answer any question—whether it’s about how we handle NFC verification, our approach to deepfake detection, the general ethics behind biometric data retention, or how we think about the future of identity. We’d love your brutal HN feedback on our APIs, platform, and integration flow!
keepamovin 4 hours ago | parent
rosasalberto 4 hours ago | parent
The main difference is that Stripe built identity mostly for their payments ecosystem, while Didit is a standalone identity infrastructure that works across any platform and any identity flow.
We also optimized heavily on fraud detection, speed, and much better pricing.
pear01 4 hours ago | parent
Are you saying your fraud detection and speed beats Stripe, or just your price?
throw03172019 4 hours ago | parent
What do you guys do different?
(Stripe identity customer)
rosasalberto 4 hours ago | parent
A few differences: - Limited global document coverage (not all IDs or countries supported). https://docs.stripe.com/identity - No advanced workflow orchestration for complex identity flows - Missing features like NFC chip verification - Pricing similar to traditional IDV vendors (expensive)
Stripe Identity works well inside the Stripe ecosystem, but companies that need more flexible, global identity infrastructure usually look for specialized solutions.
neya 4 hours ago | parent
Unless it's a government organisation, no private provider should have the ability to use or process people's identities. It's too much power in one entity's hands. I wish someone would actually solve this instead of yet another ID solutions. We all saw how a literal job seeking app (LinkedIn) abused this.
yuppiepuppie 4 hours ago | parent
rosasalberto 4 hours ago | parent
Right now the internet has a terrible model where every company asks for your ID and stores it themselves. That means your identity data ends up scattered across dozens of databases.
We think the future is privacy-preserving identity and reusability: verify once, keep your identity in your own wallet, and only share minimal proofs (e.g. “over 18” or “real human”) instead of your full identity every time.
That’s the direction we’re building toward with SSI / identity wallets and reusable verification.
eks391 29 minutes ago | parent
mothballed 4 hours ago | parent
btown 3 hours ago | parent
If I could make one giant request, it's around giving (properly authorized) humans the ability to override the system when needed. When you make a simple API, it's all too common for a company integrating the solution to rely entirely on the identity service's yes-no outcome. But all too commonly, there's no way to override a decision, or bypass the need for identification.
In the travel space, I've seen situations, especially with luxury and celebrity clients, where there's human levels of trust across the board, all parties are agreed at senior levels that they'd like to fulfill with a one-off exception to identity verification... but the technology refuses to let them proceed without going through the full verification flow, and if they're integrated in the simplest way, there's no "escape hatch" on the integration's side.
And similarly, if a person happens to trigger false negatives on video matches (say, due to medical reasons) giving support teams an ability to build exceptions is key. Having a way to tell the system "for this transaction/account ID, when they get to this node in the flow, let them through as if checks proceeded, or treat them as pre-authorized" would set you apart.
(Obviously, for things involving KYC, there's a lot of considerations around permissioning - but for many use cases, you want to empower senior support teams.)
rosasalberto 3 hours ago | parent
We also built a case management system so support teams can manually review cases, approve/decline them, or override decisions when needed. Automation handles most cases, but humans can step in for the edge cases.
beachy 2 hours ago | parent
Instead, this should be handled not by fudging identity verification but by skipping it and maybe tagging the skip event with some verified identities of the people authorizing the skip.
kmoser 1 hour ago | parent
This. Left unchecked, an entourage around a fake "celebrity" can get pretty far.
toomuchtodo 3 hours ago | parent
rosasalberto 3 hours ago | parent
In general I believe we just built a better product:
- Fastest verification on the market (inference time < 2s, well optimized infra, we do real time checks (for example when you do the front scan of the ID, we do the checks real-time, instead of waiting for the user to do the back, like persona does, and takes > 30 s, ours is less < 2 s).
- Optimized onboarding rate worldwide, global coverage, any country, low connectivity and every device accepted, and optimized (different models loading in the client depending on the speed ..etc, and many more tricks)
- Fraud detection (we analize > 200 signals, to detect fraud in real time, from IP analysis, device fingerprinting, replay attacks, deepfakes ...) we got experts on that, and we act quickly if we see new attack vectors appear.
- Developer experience (self-service, pay per usage, API first). You can start doing verifications without needed to use the UI (everything programatic), and integrate in few minutes.
- Flexible, you can create any identity flow with your own rules. You can enable features with just 1 click, no need to reintegrate.
- Pricing model (pay per usage, no monthly minimums, no enterprise gated, and low prices)
fduran 3 hours ago | parent
rosasalberto 3 hours ago | parent
bambax 2 hours ago | parent
I certainly didn't do it.
thesiti92 2 hours ago | parent
rosasalberto 2 hours ago | parent
We address this by building privacy-preserving architectures that minimize the data footprint. First, we offer secure, long-term retention so companies don't have to store sensitive PII on their own servers—which are often managed by teams who aren't cybersecurity specialists.
Second, and more importantly, we provide granular data control. Our customers can select exactly which fields they need to keep (e.g., just Name, DOB, and Country) and set the system to automatically purge sensitive assets like ID photos immediately after verification. It’s about ensuring that only the absolute minimum amount of data necessary ever exists in the system.
d1dd40135cfdc5c 2 hours ago | parent
IMO, you should spend a lot of time working on your privacy policy. I have identified a few points of concern that you should work on:
1. Your policy is immensely vague. "legally stipulated periods of conservation" means nothing. There are no references to which laws are being referenced, and there are no references to specific timeframes. Concrete detail is most needed here.
2. Under section 4, there is no mention of response timeframes (GDPR mandates 30 days), no indication of what to include in a request, and no acknowledgement of the right to escalate if Didit fails to respond.
3. You mention processing biometric data in passing and note consent as the legal basis. For special category data under GDPR Article 9, this deserves substantially more transparency -- what biometric data, how it is stored, whether it is retained after identity verification, and what happens if consent is withdrawn. One sentence is not adequate.
4. "Didit will have adopted appropriate data protection safeguards in advance" is very vague. You should specify the transfer mechanism and actually identify which third countries are involved.
5. Your legitimate interest claim for contact persons (section 2b) is asserted without any balancing test explanation, which is technically required under the GDPR.
Your information security policy is purely a mission statement. It is only a list of things you intend to do, without any explanation about how you either currently or will implement these things.
For example, "align with the highest standards of security" -- which standards? ISO 27001? SOC 2? NIST? "achieve the fully satisfactory resolution of incidents" -- what constitutes "satisfactory"? What is your incident response process?
If you intend to take data security and privacy seriously, both documents must be improved greatly before I as a consumer would consider handing my data over to this service.
vm64 2 hours ago | parent
A couple questions:
1. Given that one of your offerings is a wallet for identity, how do you handle storing user biometric data and documents
2. I’m surprised AI age detection based on faces is accurate enough to be used for account decisions. Is there any specific standard your models are held too and why would someone prefer it over an ID document proving age?
rosasalberto 1 hour ago | parent
The idea is that users control their identity. They create a Didit account where they can verify themselves, add credentials, revoke connections, or delete everything at any time. We don’t store raw biometrics or documents in the wallet layer — only derived attributes like estimated_age, is_human, is_unique, or a face embedding used for matching.
Services request specific scopes (similar to “Sign in with X”), like is_over_18 or is_human, and the user explicitly approves what gets shared.
On age detection: it’s mainly for low-risk age-gating (social, gaming, adult content, etc.), where asking every user for an ID kills conversion. For higher-risk cases you’d still use full ID verification.
mbettie 1 hour ago | parent