IDPartner offers Bank-Based ID verifications for your users. This post will explain why you’d want to use it and shows you the fast track to try it out.
Sometimes you need to know that the end user is exactly who they claim to be. You don’t actually need to scan their drivers license or passport - and, in fact, in the world of deepfakes powered by AI those solutions are becoming less and less reliable.
IDPartner relies on well capitalized, well regulated banks to solve those problems for the smaller businesses of the world who, nevertheless, want to protect themselves from fraud. A verification from a bank that “yes this person can log into a bank account” and “yes this person passed a series of 'know your customer' checks” in order to open a bank account is often enough trust. It helps to dramatically lower fraud in countries such as Canada, Sweden, and Norway.
So let’s say you want to reduce fraud. Here's a quick way to try it out.
Once you have an account on console.idpartner.com, we have a quick and easy way that enables a developer to set up a sandbox application in about 10 minutes. This blog will take you through that and future blogs will cover: using the jwt to create a new user, going into production, and integrating with a Stytch AuthN API.
Before you flip that sand-timer, though, get your account set up first. Visit console.idpartner.com to create your account, verify your email, and set up Multifactor Authentication (MFA). We ask for MFA because we really do believe that it’s our responsibility to protect the data you’ll have access to once you’re in production. Or, as CISA’s Jen Easterly puts it:
⏳Your Sandbox App in 10 Minutes
Now that you have access to the console, you can flip that timer or start that stop-watch.
The first thing you’ll do is to create your application:
You will name your application on the next screen: “login,” “checkout,” “signature block” are all fine, context-specific names you might use… but the Sandbox is a safe place to unleash your creativity so please go ahead and play.
Then we will ask you to choose your programming language - we have quick-starts available in Node JS, Java, Ruby, and Python. The rest of this guide might lean towards Node, but the other languages follow a similar pattern.
Once you hit “Create Application,” you’ll be offered the chance to go straight to GitHub, but we also have a sample application in the language you chose on the prior screen. This 10-minute guide assumes you go that route.
Once you have that zip file, open it up and extract the files. TIP: we’ve noticed some Windows users need to use 7 zip in order to extract.
Now, go ahead and open the project folder in VS Code or your IDE of choice. If you want the full tour of the code, that’s the subject of a future post. If you’re working with Node, execute npm install. For Java, Python, Ruby, or other languages, proceed with their standard dependency installation methods.
Then npm start to get it running on your local port 3001:
Now you can go to localhost:3001 to see what a user verification will look like.
Now, you are in a sandbox environment, so you won’t see the full list of over 8,000 banks on the next screen (which users would navigate with a fuzzy match when they start typing). Instead, you’re going to see a bunch of test banks from us and our partners. The user experiences do vary a lot. The best user experience leverages our demo bank, Future Bank, which you can try by downloading it on TestFlight. The quickest (no demo app required) is to try Mikomo - the Akoya test bank.
Your user is going to be asked to consent to the data that the bank (in this case a fake bank) shares with your company (GasCo in this example). This list of data is referred to as the “scopes” in OpenID Connect and, at the end of this blog, I will show you how to edit the ones you request and receive in index.js in the test project folder.
Once the user allows access, they will login directly with the bank.
Creds:
Username mikomo_10
Password mikomo_10
From here, you are seeing bank screens (in this case, a test bank). Note that the Mikomo test bank occasionally errors and lands you on an account screen. If that happens, you should start the flow again… this is just an issue with the demo bank. Take it up with the demo gods 🙏🐑🙏
IDPartner’s FutureBank flow will show you how we are working with bank partners to make it a more seamless, user friendly - not to mention secure - experience. You can get the app on TestFlight and give it a try.
Once you’ve been through each of the bank screens and provided the bank with your consent, you land back on your local with a success screen.
Well done! I hope you made it in ten minutes, there or thereabouts, and I hope you see how easy it can be to verify your users using the power of their bank’s know-your-customer and authentication systems. ⌛
Next, we’ll publish a couple other posts aimed at enabling you to adapt the request, use the jwt to create a user in your system, go into production, and integrate it with the Stytch AuthN API.
