SPONSORED BY MASTERCARD
What is KYC and why is it so challenging?
At its most basic, Know Your Customer (KYC) is a due diligence process used to verify that the person is who they say they are and that data they have shared is correct (e.g. phone number, email, and address). KYC regulations are in place to prevent criminal activities such as identity fraud, money laundering, and other financial crimes. However, the compliance and implementation of these regulations comes with a host of challenges. Some of these challenges include:
- Customer identification: You’ll need to compare the customer’s likeness with a photo on an approved ID card (usually government-issued like a passport or driver’s license). There is additional friction if this happens in-person.
- Documentation verification: Making sure the picture matches the person isn’t enough; the government-issued ID of the individual must be checked for forgery or tampering. This requires the person carrying out the verification to be trained to recognize these signs and look for the presence of appropriate watermarks, etc.
- Address verification: As an additional check on their documents, the customer must provide proof that they live at the address on the government-issued ID documents (Proof of Address or POA) usually by providing recent utility bills. This is getting trickier as many of us opt for electronic bills, so the customer may have to request one-off letters from approved sources to prove they live at the address they’ve provided.
- Verify contact details: Finally, you’ll need to check that the email address and phone number provided are correct and belong to the customer. A common approach is to support a one-time-passcode (OTP) system that allows a customer to enter the passcode they receive and have it linked to the account profile that is being created.
For software developers, all of these steps slow down your user onboarding. Many of these verification steps are manual and some require the customer to come in to meet face-to-face, which adds friction to the onboarding experience. This manual process creates additional costs for the organization performing the validations.
KYC can have multiple layers of customer verification such as anti-money laundering checks and risk assessments—for example, using Ekata to spot if an address provided has being used repeatedly before for fraudulent transactions. It can even include checking an individual’s crypto footprint for inappropriate transaction history or if they’re on a sanctions list (Ciphertrace).
For the purposes of this post, we’re going to look at how Mastercard Open Banking Account Owner Verification APIs can help support the most fundamental step in a KYC pipeline: verify the digital identity of your consumers or small businesses based on their provided name, address, and contact details.
But the banks have already done KYC for their customers!
Yes, the banks have built a rigorous KYC practice to verify customers before they open any account. Banks adhere to a range of regional privacy, security, and anti-money laundering regulations. Many of us have had to go through that process of providing proof of identity and address as well as completing registrations using OTPs sent to our email and phone. An important consideration is how we as customers also keep this information up to date, so we don’t miss any important communications from our bank.
The timeliness, quality, and accuracy of the customer data that the bank holds is very useful, but also valuable because of the time and effort invested in collecting it and keeping it up to date. The US Open Banking API enables you to unlock this value. Specifically, we can use the Account Owner Verification API to access this valuable data.
Using Mastercard Account Owner Verification APIs to leverage the bank’s KYC efforts
Open banking empowers users (consumers and small businesses) to access, use, and benefit from their own financial data. They can control what accounts can be seen, how long that access can be granted, and for what purpose— things like opening new accounts, securing loans, improving credit scores, and enabling consumer choice in payments.
The user (your customer) feels safe doing this because they are authenticating directly with their bank using their online banking credentials, giving them confidence that the third-party won’t see or store them.
The US Open Banking API handles a trusted connections to the banks, provides a secure dialog so the account holder can authenticate, and caches the financial data so when you execute a query it comes back quickly (avoiding a round trip to the bank every time).
The US Open Banking API provides a range of features including account aggregation, payment enablement, and confidence scores that can be used for financial services use cases like lending, payments, and account opening.
To help support your KYC pipeline, we can use Mastercard’s Account Owner Verification API, which returns bank pre-verified data (i.e. name, email, address and phone number) along with identity insights and an identity risk score based on users’ activity pattern and its association to help detect fraudulent behavior, thereby instantly verifying that the user (bank account owners) are genuine and help mitigate online fraud. This makes it exponentially harder for criminals to use real or fake IDs to commit fraud and significantly reduces identity fraud by enhancing the effectiveness of fraud detection systems for account openings, me-to-me (M2M) transfers, peer-to-peer (P2P) transfers, bill payments, and other transactions.
How it works
- Your server registers a customer with Open Banking and receives an ID for this customer.
- With this customer ID, your server can generate a redirect URL for loading the connect experience that will allow the customer to connect to their bank.
- Your frontend application redirects the customer to connect using the generated URL from step 2.
- The customer logs into their financial institution using their bank credentials through the connect experience.
- The customer grants permission for their financial data to be accessed.
Once the customer has granted you access to the account, you make a call to the Get Account Owner Details API.
The Get Account Owner Details API is aligned with the Financial Data Exchange (FDX) standards. The FDX is dedicated to unifying standards for secure and convenient access of user-permissioned financial data sharing throughout the financial services industry. This allows the API to return the payload about the user (consumer or small business) in a standard format with the following details:
- Names: The names of the account holders. It will also indicate whether it is a person, business, or other entity.
- Address: The standard format for a US address, broken into constituent parts, which will also have an entry to say if it is a business or home address.
- Phone numbers: An array of contact phone numbers along with type (Personal/Business).
- Email addresses: An array of email addresses and their type (Personal/Business).
- Documentation: An array of the document proofs provided: tax identifier SSN, government-issued ID (passport number, visa number, driver’s license number, etc.) Quick sidebar: though this element is a required field in some regions, it is not mandatory in the US, and as such, it is at the discretion of the bank.
Example response
{
"holders": [
{
"relationship": "AUTHORIZED_USER",
"ownerName": "John Smith, PhD",
"firstName": "John",
"middleName": "L",
"lastName": "Smith",
"suffix": "PhD",
"nameClassification": "person",
"nameClassificationconfidencescore": 100,
"addresses": [
{
"ownerAddress": "434 W Ascension Way",
"type": "Home",
"line1": "434 W Ascension Way",
"line2": "Suite #200",
"line3": "UT 84123",
"city": "Murray",
"state": "UT",
"postalCode": "84123",
"country": "USA"
}
],
"emails": [
{
"isPrimary": true,
"email": "myname@mycompany.com",
"emailType": "Personal"
}
],
"phones": [
{
"type": "HOME",
"country": "61",
"phone": "1-801-984-4200"
}
],
"documentations": [
{
"taxId": "123-45-7890",
"taxIdCountry": "USA",
"governmentId": "123456789"
}
]
}
]
}
Congratulations! Now you have the data (verified by a bank) necessary to enhance your customer onboarding process.
How are the account holder’s credentials secured?
The US Open Banking Service uses OAuth when integrating into the bank APIs and as a third party in that process, it never sees the account holder credentials. When the account holder successfully authenticates with their bank and selects the account they want to allow access to and for how long, the service will get a token that it encrypts and stores until it needs to access the data. It will be limited to just the data that the account holder has explicitly granted access to.
If you are using the Get Account Owner Details API as part of a one-off customer onboarding verification step, you can set the token up to be a single-use token to further limit access to the account owner data. If, however, it is part of a broader Account Opening process, Account Aggregation or similar Open Banking use case, you can configure the token to live for a longer period of time.
How do I get started?
Check out this Quick Start Guide on Mastercard Developers to get up and running with the US Open Banking API and then use the Get Account Owner Details API call to pull the data necessary to power your KYC process.