Confirm overview
Institutions across the globe experience a high number of payment returns and fraud due to the inability to verify account information prior to payment processing, resulting in additional fees, payment delays, and an overall poor customer experience.
Watch the video to learn how Confirm can help you reduce the risk of failed payments and fraud by pre-validating account information before sending a payment to a first-time beneficiary and for high-value wire transfers.
Kaitlin DeWolf
Hello. I'm Kaitlin, and I'm a product manager on the Confirm team. Our application, Confirm, is a global peer-to-peer account validation product. Our participants use the application to verify account information is correct prior to sending payments, during onboarding and operations processes, and just for data hygiene. Confirm sources its data directly from other participants who get paid for validating account information. The application is designed to be used by an API. However, we also offer a user interface, which I'll use to demo the product.
I'll start this demo by acting as an inquiring participant that uses the user interface to validate account information. The first page is the Sent Inquiries grid that shows a user their historical inquiries. This data can also be exported to CSV. Now, I'm going to demonstrate how an inquirer generates an inquiry. We support bulk upload via CSV, but I'll show you the single inquiry flow.
To create an inquiry, you only need an account number, bank identifier, and an accountholder's name. For the purpose of the demo, I will pretend to validate an account at JP Morgan using a SWIFT identifier. We support global payment methods and expand the allowed fields based on market demand.
This next section is where you choose the information you would like to validate. Today, you can validate an account status, ownership, and transaction activity. However, these request fields will expand to include more data elements over time. To validate a name, you must provide an input name. To validate transaction activity, you must provide a time period. Finally, you will select the network participant this inquiry should be sent to.
I will now submit the inquiry. I am now brought back to the Sent Inquiry page we started on. You can see here that my inquiry was sent and is still awaiting a response. In production, the response will automatically come back within seconds because all responding participants are integrated to our system via API.
Now, I'm going to switch my role and act as a responding participant. Again, responders are all API users, and I'm only going to walk through the user interface to demonstrate how a response would work. This is the Received page that shows the inquiries my institution has historically responded to and the inquiries which are still awaiting a response. I'm going to select the inquiry I just sent and generate a response.
On the right panel here, you can see the information provided in the inquiry. A responding participant will use this information to generate a response. First, I'll respond to account status. The options for responding are Open, Incorrect Account Number Format, Closed, Cannot Confirm, and Reject.
Next, I'll respond to account owner name. The options for responding are Full Match, Partial Match, and No Match. I can also optionally provide the correct accountholder name. Finally, I'll respond to transaction activity. The options for responding are Activity, Exception, and No Response.
Activity means the responder has experienced successful transactions with the account. Exception means the responder has experienced issues when trying to transact with the account. And no response means the responder hasn't transacted with the account or cannot provide data on the account. As you can see here, the response I just generated can now be seen on the Inquiries Received grid and can also be seen when I switch to the Sent Inquiries grid. This concludes the overview of Confirm.
Thank you.