### Is Express Verify the same thing as Verify+?

Express Verify is deprecated. I believe you have API docs that refer to the replacement as "Verify+" - we refer to that suite of products today as "Account Insights" and an overview can be found here: https://developers.achq.com/docs/bank-account-tools

### Our understanding is that Express Verify is not something we have to integrate with, but is something the customer can choose to turn on. It will prescrub transactions that are likely to fail before they get sent. Is this accurate?

Account Insights is an API first service but we designed native automation that enable access to the service without any technical lift. The ruleset trigger options are:

* **First time WEB**
Verifies bank status only the first time it is submitted with a WEB SEC code. Satisfies Nacha minimum requirements
* **First time ANY**
Verifies bank status the first time an account is submitted regardless of SEC code
* **All payments**
Verifies bank status on every payment whether it is the first time or not. Great for higher-risk or fraud sensitive merchants

The automated service is enabled at the "merchant profile" level and just works.

A few things to consider:

* The rules use the "[Account Status](https://developers.achq.com/docs/bank-account-tools#account-status-api)" service which verifies the status - good, bad, etc - of a bank account
* "[Account ID](https://developers.achq.com/docs/bank-account-tools#account-id-api)" which first verifies status and then confirms ownership data is only available via API.
* Downside of using the ruleset is that access is limited to payment creation whereas certain users prefer to run verification more top-of-funnel.
* If using the API the status is returned in the request. The rulesets are async and typically fire a handful of minutes after db commit for a payment (can get exact timing here for you)
* Coverage is quite good 87-90% result in a decision. We use real-time data from the Zelle network, internal history, and data consortiums.

### Do Express Verify rejections work well in LoanPro?

From our understanding LoanPro reports on the status just fine but AutoPal does not. One of our largest mutual customers (Octane/RoadRunner) has been using the Account Status ruleset to great success on all "first time" payments and (I think) is moving to all payments being verified. The below is a sample of about ~60k requests:

### What happens if the account fails verification?

The transaction is "Rejected" - similar to a return - and assigned the corresponding status code:
https://developers.achq.com/docs/bank-account-reponses

### What is the cost to turn on Express Verify, and does the mutual client do that directly with you?

Full transparency: Our aggregate costs are ~0.25 and ~0.47 for status/ID respectively.

If using the rulesets/Status we charge $0.35 per event, which is below market rate. At scale customers like Octane pay just a few cents over cost.

Account ID is typically sold at $0.75 - $1.00. We do quite well with our direct API customers positioning the ID endpoint as a waterfall for when Plaid/MX fails or is unavailable due to account type. Way better than microdeposits.

Some platform partners choose to integrate the APIs and further monetize the service where we esentially give it at cost+ a few cents and bill the platform for usage.

The automatic rules need to be enabled by our team whereas API access would be universal.