Learn more about our news and offerings.

Zach Chestnut

Hi. I'm Zach from the CheckMatch team. CheckMatch is a way to streamline check processing, which can reduce operational costs and minimize the carbon footprint for check originators as well as lockbox providers.

Did you know that if you go to your retail banking app today as a consumer and set up a bill pay payment, there is a decent chance that that may result in someone somewhere printing a physical check and physically sending that check through the mail?

This adds up quickly. There were 14 and 1/2 billion check payments in the United States in 2018 with an estimated average processing cost of $1.22 up to four to seven days in processing time and, unfortunately, a significant carbon footprint from putting those items on trucks and planes. We asked ourselves why. And we asked ourselves, how can we make this better? This is how CheckMatch was born.

CheckMatch is a two-sided marketplace comprising check originators like bill pay and check print providers on one side and lockbox providers on the other. Lockbox providers upload address data to the network. And then check originators submit transactions to the network and identify matches.

For matched items, CheckMatch facilitates the secure transmission of payment information from the originator to the lockbox provider. And CheckMatch also provides an image of a printed physical check in accordance with US federal regulation. You'll note that this is the exact same information that a lockbox provider would receive as part of their business-as-usual operations, only far more efficient.

Originator clients can save the expense of printing and mailing a physical check. And lockbox clients can save the effort of opening mail and processing physical items. CheckMatch communicates via API, but we can also support file-based integrations where required. That's a quick review of CheckMatch. Thanks for your time and attention.

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.