There are a couple of options. We recommend a “just-in-time” approach where user accounts and passwords are moved over as users log into the new system. The big advantage is that customers don’t have to reset their password and there’s no impact on user experience. The other approach is a “bulk migration” where you export all of the customer records from the old system and load them into Strivacity. This requires every customer to reset their password. This blog post covers these two options in much more detail.

Strivacity’s native consent management capability lets you push consent requests out to customers for things like new terms and conditions, privacy policies, or communication preferences. Consent receipts are stored so customers (and administrators) can easily see them. You can also push receipts out to a consent management platform (CMP) if you want. Also, when you create new versions of a policy, for example, you can require users to approve the new version the next time they log in.

Strivacity has a native identity verification capability. Most customers use it as part of the new user sign-up process when they require stronger evidence that users are who they claim to be. We can look up the user’s personally identifiable information (PII) against third-party data sources to make sure they match. We’ll match against things like phone records and national ID numbers like U.S. social security #’s or Canadian national IDs). We can also do knowledge-based verification against credit bureau data. If you have proprietary info we can match against that too.

Strivacity is “built in the cloud”. That means we’re able to take advantage of all of the latest technologies and auto-scaling capabilities that cloud providers offer. When login activity spikes (think of everyone turning on Netflix at 8pm) Strivacity automatically spins up as many new servers as necessary in the background so that there’s no performance impact to your customers.