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.)
This is a great point. In Didit you can already configure this kind of flexibility. For example, you can set rules like “if email/phone = X, skip ID verification” or route the user through a different flow.
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.
This sounds innately wrong. When we think of celebrity clients traveling but skipping any identity checks because their entourage can vouch for them and don't want to hassle them - then who's to say later whether that person did or did not travel to that island or authorize that money transfer?
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.
Great instincts! It would be less the entourage and more an accredited travel agency with established reputation. And absolutely correct that the skip should be auditable and intentional - and having support at the provider level for this makes this more auditable, not less.
Given all the privacy breaches already in this space, what auditing are you planning to ensure that PII is not held anywhere in the stack after KYC/AML/ID confirmation?
This goes beyond ISO27K/HIPAA/SOC2 etc to an actual code/storage audit that confirms that PII is only held ephemerally and completely encrypted at rest otherwise, unavailable to anyone, including internal access and/or law enforcement etc.
What’s your extraction layer under the hood? BlinkID? Regula? KBY? Another IDV provider? Self-hosted OCR model/extraction layer?
This is an interesting concept but the identity space is extremely crowded. It’s hard to find a specific niche and aggressively scale it unless you already have a strong end-user persona in mind, precisely because interacting with “the real world” is super nuanced and complicated at any appreciable scale.
This is interesting... how does it differ from companies like YOTI (https://www.yoti.com/) who I believe are trying to solve a similar problem at scale?
Love the focus on KYC. I've always wondered why there isn't a centralized identity verification process that makes it easy for beneficial owner reporting for companies. Every financial institution collects this and it's still a manual process that requires inputting the same info over and over again.
Congrats on the launch! Hard to judge from just demo videos but the flow seems much nicer than those I’ve encountered in many apps.
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?
It’s not public yet — the identity wallet is still in private beta.
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.
Not only is it PII, it is also a biometric identifier under BIPA [0]. Perhaps moreso than a facial image alone (depending upon your interpretation of the law).
> "Biometric identifier" means a retina or iris scan, fingerprint, voiceprint, or scan of hand or face geometry. Biometric identifiers do not include writing samples, written signatures, photographs, human biological samples used for valid scientific testing or screening, demographic data, tattoo descriptions, or physical descriptions such as height, weight, hair color, or eye color.
I like that it lets you specify the types of accepted docs. The biggest issue i have with Stripe identity verification product right now. And biometric re-log in is also great. Will check it out.
What information do you store about the users? Are you storing all of the identification documentation, or do you only store proof about the fact that you verified the user identity and age?
To me that’s a winner if I’m paying for a SaaS. If I have to go through a procurement cycle to talk to you instead of busting out my card I’m probably going to look and make sure no one else is remotely equivalent first that does self service. If someone else is giving rough feature parity and offers self service they will always win. Even if the self service is more expensive the convenience of me not having to talk to you is gonna get outweighed by that.
I don’t need to chat with you where you do a q&a where you decide what the correct amount of money to extract out of me is. Price your service accurately and accordingly instead and you’ll get my business
Suerte! Unrelated, growing up in Spain it always baffled me that identification was based on a photo on your DNI. Stories of siblings or even friends that had a passing resemblance to each other sharing DNIs was a common story.
Spain didn’t really integrate many of the newer innovations in identity verification for a long time. Luckily things are improving, and we’re already working with some great companies there. Saludos!
Stripe Identity is good, especially if you already use Stripe.
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.
with all this talk about persona/discord sending identities to the dhs and everything, what steps do you guys take to keep identity information private?
I don't have the full context on the Persona/Discord story yet, but our philosophy is that identity providers should be a shield, not a source of risk.
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.
If you don't "have the full context on the Persona/Discord story" you should work on getting it.
It's literally the first thing that came to mind when I saw your post and not having a convincing/satisfying answer in direct relation to that catastrophe doesn't bode well for getting people to trust your brand. The rest of your answer is essentially the absolute minimum I'd expect from a business like this, but not sufficiently convincing.
> 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.
What privacy preserving architectures are you implementing? How are you securing PII?
(I want to emphasize that my intention is not to criticize Didit negatively. Rather, I aim to offer constructive feedback.)
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.
I'm not affiliated with Didit, I run a separate company (https://cerebrum.com). We offer an IDV product and we work with a network of ~40 background screening companies in the US and are integrated to basically every ATS/HRIS system as a result.
If you are in the US, be extremely careful when implementing KYE/HR workflows due to FCRA risk. Glad to speak on this if you're interested or have a need! My email is sebastian @ <ourcompanyname>.com
Stripe builds great products, including identity. But it’s not a specialized identity platform.
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.
There is many direct competitors in the space, the main ones are Persona, Jumio, Incode, Sumsub, and even orchestrators like Alloy.
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)
Here's a better idea: Eradicate requirement of the most personal details of someone to do basic tasks...such as using a web application.
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.
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.
This is neat. I had a conversation recently basically concluding that "it would be nice if an identity solution existed where [everything you just said, consolidation of identity, but only providing the minimum for regulation, like age, location, or is-human, depending on the law a site is trying to follow], instead of [all the gross examples of identity consolidation abuse seen today and the source for ID company distrust]". I hope luck for you, so your product both maintains the vision long term, sustains market share for longevity purposes, and sets a standard for others to follow.
Id say this is a valid criticism of the b2c market (esp. for social networks). but there still is a viable b2b market where kyb/c is not as intrusive - and sometimes a regulatory requirement (finance, health, etc.).
These 'identity verification' companies end up becoming a main enemy of this pursuit. Their own revenue relies on legislation that assures their existence.
Great to see innovation in this space!
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.)
This is a great point. In Didit you can already configure this kind of flexibility. For example, you can set rules like “if email/phone = X, skip ID verification” or route the user through a different flow.
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.
This sounds innately wrong. When we think of celebrity clients traveling but skipping any identity checks because their entourage can vouch for them and don't want to hassle them - then who's to say later whether that person did or did not travel to that island or authorize that money transfer?
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.
> and maybe tagging the skip event with some verified identities of the people authorizing the skip
This. Left unchecked, an entourage around a fake "celebrity" can get pretty far.
Great instincts! It would be less the entourage and more an accredited travel agency with established reputation. And absolutely correct that the skip should be auditable and intentional - and having support at the provider level for this makes this more auditable, not less.
Looks like an awesome launch.
Given all the privacy breaches already in this space, what auditing are you planning to ensure that PII is not held anywhere in the stack after KYC/AML/ID confirmation?
This goes beyond ISO27K/HIPAA/SOC2 etc to an actual code/storage audit that confirms that PII is only held ephemerally and completely encrypted at rest otherwise, unavailable to anyone, including internal access and/or law enforcement etc.
What’s your extraction layer under the hood? BlinkID? Regula? KBY? Another IDV provider? Self-hosted OCR model/extraction layer?
This is an interesting concept but the identity space is extremely crowded. It’s hard to find a specific niche and aggressively scale it unless you already have a strong end-user persona in mind, precisely because interacting with “the real world” is super nuanced and complicated at any appreciable scale.
This is interesting... how does it differ from companies like YOTI (https://www.yoti.com/) who I believe are trying to solve a similar problem at scale?
Love the focus on KYC. I've always wondered why there isn't a centralized identity verification process that makes it easy for beneficial owner reporting for companies. Every financial institution collects this and it's still a manual process that requires inputting the same info over and over again.
Congrats on the launch! Hard to judge from just demo videos but the flow seems much nicer than those I’ve encountered in many apps.
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?
It’s not public yet — the identity wallet is still in private beta.
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.
Unlike your other examples, a face embedding is PII (it is designed to uniquely identify a person). So you are storing PII.
Not only is it PII, it is also a biometric identifier under BIPA [0]. Perhaps moreso than a facial image alone (depending upon your interpretation of the law).
[0]: https://www.ilga.gov/Legislation/publicacts/view/095-0994
> "Biometric identifier" means a retina or iris scan, fingerprint, voiceprint, or scan of hand or face geometry. Biometric identifiers do not include writing samples, written signatures, photographs, human biological samples used for valid scientific testing or screening, demographic data, tattoo descriptions, or physical descriptions such as height, weight, hair color, or eye color.
I like that it lets you specify the types of accepted docs. The biggest issue i have with Stripe identity verification product right now. And biometric re-log in is also great. Will check it out.
Yes! thanks! anything let us know
What information do you store about the users? Are you storing all of the identification documentation, or do you only store proof about the fact that you verified the user identity and age?
There are a bunch of competing companies in that space but it's true that transparent pricing and self-service is rare. Good idea to focus on that.
To me that’s a winner if I’m paying for a SaaS. If I have to go through a procurement cycle to talk to you instead of busting out my card I’m probably going to look and make sure no one else is remotely equivalent first that does self service. If someone else is giving rough feature parity and offers self service they will always win. Even if the self service is more expensive the convenience of me not having to talk to you is gonna get outweighed by that.
I don’t need to chat with you where you do a q&a where you decide what the correct amount of money to extract out of me is. Price your service accurately and accordingly instead and you’ll get my business
agree 100%
Thanks! transparency and frictionless access always wins long term
This is really cool (especially considering that the pricing is way better than Persona/Stripe Identity)!
That being said, what security measures does Didit take, and has it gone through e.g. auditing or SOC 2?
Thanks! We have ISO27001, iBeta PAD, and about to receive SOC 2. We also do bug bounty programs, and pen-testing.
Can't see any mention of bug bounties on your site - do you have any details you could share?
Suerte! Unrelated, growing up in Spain it always baffled me that identification was based on a photo on your DNI. Stories of siblings or even friends that had a passing resemblance to each other sharing DNIs was a common story.
Spain didn’t really integrate many of the newer innovations in identity verification for a long time. Luckily things are improving, and we’re already working with some great companies there. Saludos!
Stripe has a pretty good identity system already. What do you think of it?
Stripe Identity is good, especially if you already use Stripe.
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.
Isn't it useful to pair identity with common reasons to identify? Why else would you ask?
Are you saying your fraud detection and speed beats Stripe, or just your price?
Yes, we mog on speed, onboarding rate, fraud detection, and price.
> Yes, we mog English please
https://www.merriam-webster.com/slang/mog
with all this talk about persona/discord sending identities to the dhs and everything, what steps do you guys take to keep identity information private?
I don't have the full context on the Persona/Discord story yet, but our philosophy is that identity providers should be a shield, not a source of risk.
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.
If you don't "have the full context on the Persona/Discord story" you should work on getting it.
It's literally the first thing that came to mind when I saw your post and not having a convincing/satisfying answer in direct relation to that catastrophe doesn't bode well for getting people to trust your brand. The rest of your answer is essentially the absolute minimum I'd expect from a business like this, but not sufficiently convincing.
> 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.
What privacy preserving architectures are you implementing? How are you securing PII?
(I want to emphasize that my intention is not to criticize Didit negatively. Rather, I aim to offer constructive feedback.)
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.
thanks for the feedback! definitively we can improve there!
Just wanna compliment you guys on your UI/UX. App is really well designed, smooth, slick.
Any specific features or plans on know your employees/ HR hiring workflows ?
I'm not affiliated with Didit, I run a separate company (https://cerebrum.com). We offer an IDV product and we work with a network of ~40 background screening companies in the US and are integrated to basically every ATS/HRIS system as a result.
If you are in the US, be extremely careful when implementing KYE/HR workflows due to FCRA risk. Glad to speak on this if you're interested or have a need! My email is sebastian @ <ourcompanyname>.com
Any plans for B2B verification?
Yes, about to launch KYB this month!
Looks like an awesome launch.
“Stripe for XXXX” is an odd description when Stripe does the XXXX feature.
What do you guys do different?
(Stripe identity customer)
Stripe builds great products, including identity. But it’s not a specialized identity platform.
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.
Who would you say is your primary competitor (besides Stripe) and how are you better than them today?
There is many direct competitors in the space, the main ones are Persona, Jumio, Incode, Sumsub, and even orchestrators like Alloy.
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)
Seon, Comply Advantage. There's lots of competition here.
Comply Advantage specializes in AML, Seon as well.
They provide one signal, identity verification is more than that.
They both offer IDV products and have entrypoints into enterprises as a result of their AML/KYC offerings.
IDV always reminds me of that Norm joke about ID:
“The I stands for I, and the D stands for Dentification”
Here's a better idea: Eradicate requirement of the most personal details of someone to do basic tasks...such as using a web application.
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.
We actually agree with the core concern.
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.
This is neat. I had a conversation recently basically concluding that "it would be nice if an identity solution existed where [everything you just said, consolidation of identity, but only providing the minimum for regulation, like age, location, or is-human, depending on the law a site is trying to follow], instead of [all the gross examples of identity consolidation abuse seen today and the source for ID company distrust]". I hope luck for you, so your product both maintains the vision long term, sustains market share for longevity purposes, and sets a standard for others to follow.
Id say this is a valid criticism of the b2c market (esp. for social networks). but there still is a viable b2b market where kyb/c is not as intrusive - and sometimes a regulatory requirement (finance, health, etc.).
These 'identity verification' companies end up becoming a main enemy of this pursuit. Their own revenue relies on legislation that assures their existence.
Nice to see a Spanish startup in YC :) Good luck!
thanks! Spanish founders mog!
Didit?
I certainly didn't do it.