3 ms·

If your chief risk officer is any good, they will start raising red flags all over if you suggest in-housing KYC fully. You suddenly have to think about stuff

by mpeg 4y ago

If your chief risk officer is any good, they will start raising red flags all over if you suggest in-housing KYC fully. You suddenly have to think about stuff like: - where are you storing the passport data? Who has access to it? How is it processed? - what’s the process in case of a data breach, what regulators must be notified - what data sources are you querying? Sanctions lists, etc. how often are they updated? - do you need to support one country only, or multiple? Each country will have their own quirks in the process That’s just off the top of my head.

alonp99 4y ago
Again, good points! this is exactly what we want to take off of the dev/CTO shoulders when going into the CRO’s office, we might need to do a better job communicating what the project is about. - You can choose where to store the data, you can either keep it in the vendor's hand if it's more comfortable for the CRO or use your own AWS and GCS for specific geographies (e.g. GDPR). for those who have access to the data we have RBAC built-in into the back office, we’ve seen that most companies are actually building their own back office since identity verification providers usually won't give something operational for manual approvals - so getting one that is built with best practices in mind and maintained by a community is a big benefit in a security aspect. - Each company that deals with such processes have its own regulatory framework they are under and they are obliged to assign personnel to build and maintain a policy and make sure the company acts according to it it. - You can orchestrate that entirely, using whatever data source you need, by using an existing integration or adding a new one. - This is a big plus for having a community that is spread across multiple geographies and can help build local solutions that will make the system global (stuff like which data you need to collect, how much time data should be stored, in what area it should be stored, and which vendors works best with specific data).
- mpeg 4y ago
  It makes sense, I didn’t really mean my comment as a dismissal of your product btw; I understand that you’re trying to build a set of tools that cover the whole range of what a company might need to do KYC — you’re not really competing with onfido in that sense, as the next onfido could use your product as a building block (or acquire you).

by mpeg 4y ago

alonp99 4y ago

Again, good points! this is exactly what we want to take off of the dev/CTO shoulders when going into the CRO’s office, we might need to do a better job communicating what the project is about. - You can choose where to store the data, you can either keep it in the vendor's hand if it's more comfortable for the CRO or use your own AWS and GCS for specific geographies (e.g. GDPR). for those who have access to the data we have RBAC built-in into the back office, we’ve seen that most companies are actually building their own back office since identity verification providers usually won't give something operational for manual approvals - so getting one that is built with best practices in mind and maintained by a community is a big benefit in a security aspect. - Each company that deals with such processes have its own regulatory framework they are under and they are obliged to assign personnel to build and maintain a policy and make sure the company acts according to it it. - You can orchestrate that entirely, using whatever data source you need, by using an existing integration or adding a new one. - This is a big plus for having a community that is spread across multiple geographies and can help build local solutions that will make the system global (stuff like which data you need to collect, how much time data should be stored, in what area it should be stored, and which vendors works best with specific data).

mpeg 4y ago
It makes sense, I didn’t really mean my comment as a dismissal of your product btw; I understand that you’re trying to build a set of tools that cover the whole range of what a company might need to do KYC — you’re not really competing with onfido in that sense, as the next onfido could use your product as a building block (or acquire you).