Traditionally, companies have spent millions of dollars and countless development cycles building and iterating on complex onboarding forms to balance conversion, business functions, and in cases where identity really matters — verification accuracy. Over the last decade a new concern became a necessity in this discussion: security.

As identity on the internet became a requirement (KYC) for more types of businesses like Financial institutions, payments, retail, and marketplaces — protecting the data behind those identities became a serious problem and one that not only causes real damages to people and businesses but also became a key requirement in all sorts of compliance frameworks like SOC2, PCI, and FINRA regulations.

Over the last decade a number of solutions of entered the market to help businesses solve these exact types of problems: vaulting providers. These are general purpose solutions designed to take IN sensitive data and spit OUT tokens. A token is really just a random string of numbers and characters representing a record protected by the vaulting provider.

Some businesses built their own special purpose vaults for various types of data — the more sophisticated ones had fairly comprehensive systems built out with a small army of engineers to build and maintain the software that played a critical foundation layer underneath all the core infrastructure. However, as these things go — it doesn’t make sense for every business (or even most) to reinvent this wheel. Doing so is difficult and has a high cost of ownership that touches bespoke features, cryptography, and performance.

Standalone Vaulting, the Problem

These general purpose vaulting providers are expensive both in dollar cost but also the dependence it forces upon companies as they have these tokens floating around their database. A proper onboarding flow for a person’s basic details (name, date of birth, address, SSN, etc) could equate to more than 10 tokens (and even more if you extract data from an identity document).

This means that businesses still have the full cost of writing their own schema, building the frontend onboarding user experience, and connecting it all together to securely tokenize all the sensitive customer data. For any given row, there’s now a handful of database columns that just hold these opaque tokens.

As companies change their onboarding flow, or build out additional ones for new products with different compliance/data collection requirements, companies in turn grow the complexity of their schema. This is not too dissimilar as developers would if the data was stored directly there in plaintext. Your database grows with more of these opaque tokens, but the onboarding data model does not become any simpler.

One Footprint fp_id

We’ve already talked about the many Onboarding features that Footprint delivers: extensive customization for look and feel, granular Playbooks for collecting variable types of identity data paired with exhaustive rules engine for dynamically controlling step-ups, embedded fraud behavioral analysis, and more. What we perhaps discuss publicly less is how the same onboarding makes our vaulting better. This is because Footprint’s embedded onboarding experience integrates seamlessly with the Footprint Vault that simplifies and solves for the many problems outlined above.

The fundamental difference is that Footprint understands onboarding, and that means the Vault for your users’ data is purpose built with a schema, permissioned IAM controls, and most importantly all of the complexity is baked into a single identifier — or token — that you need to store on your database — the user’s Footprint ID or fp_id.

For businesses with multiple products and onboarding flows (controlled by different Footprint Playbooks), the user data schema transparently supports everything. The embedded onboarding flow is smart enough to only ask for the information it doesn’t yet have on the user (the rest is confirmed via autofill).

Finally, the singular fp_id token can be used to easily access all the of the data securely using decrypting APIs or the Vault Proxy. For instance, the full SSN is fp_id_xyz.id.ssn9 or the last 4 digits of the SSN is fp_id_xyz.id.ssn4. If you’re using Footprint to store users’ credit cards on the vault, this works transparently too: fp_id_xyz.card_1.number.

Pertinently, the embedded onboarding flows securely vaults all of the data so it never needs to touch your systems during collection keeping you and your systems out of scope for complex compliance regimes.

Better for Developers and Users

With Footprint, Vaulting and Onboarding work better together and complement each other. It simplifies the developer integration and time to deploy, future proofs you for future product lines, and most importantly ensures you stay secure and compliant with the most sensitive user data as it flows through your products.