What is the Member Alert to Control High-Risk Merchants (MATCH), and What Does It Mean to PFs?

Before onboarding merchants, all payment providers are responsible for conducting due diligence on those merchants to verify their identities and to guard against fraudulent or criminal activity.

One of the pieces of this puzzle involves checking the details known about the merchant against databases with entities the payment provider should avoid. These databases provide valuable information from different perspectives. For example, the U.S. Treasury Department’s Office of Foreign Asset Control (OFAC) publishes a list related to U.S. foreign policy and national security interests.

The payments industry has its own list, commonly known as MATCH. MATCH stands for the Member Alert to Control High-Risk Merchants. Hosted by Mastercard, MATCH is a database of merchants and individuals who have been terminated by their acquirers for cause. It serves as a repository for information about entities that have done something wrong within the payments ecosystem itself.

MATCH and payment facilitators

The card networks, such as Visa and Mastercard, require acquiring banks to run MATCH checks on prospective new merchants. The networks do not have relationships directly with payment facilitators – their relationships are with the acquiring banks. Yet because payment facilitators are doing the onboarding, this responsibility is passed to them.

In most cases, that means the PF must implement a way to pass merchant and owner / principal data to the acquirer to run a MATCH check. The acquirer will then pass the information to Mastercard to run the check, and the results will be passed back to the PF.

Established acquirers will likely have a process for passing the data; implementing what is needed to make that happen is the responsibility of the PF. Companies that provide software and other infrastructure for PFs have also developed ways to simplify this process.

PFs also must be aware of other MATCH processes that go beyond a single check at onboarding. The database itself relies on acquiring entities (including PFs) to populate it with information about the merchants they have terminated, within a prescribed time period.

This means that whenever a payment facilitator terminates a merchant, they must determine whether the entity has done something that warrants being added to the MATCH list. PFs are expected to have the proper standards and procedures in place for adding their own terminated merchants to the MATCH system within the required timeframe, again via a passing of information to their acquirer.

Acquirers will also have processes in place to update a PF as to whether any existing merchants have been added to the MATCH list by another acquirer, called the “retro-match” process. MATCH relies on continuous actions from acquirers, which means that any updates are not instantaneous.

For example, a bad acting merchant can get shut down by one acquirer and then immediately apply to open an account at another acquirer. That new acquirer may screen the merchant against the MATCH system and receive a negative result initially, but the original acquirer could add them shortly thereafter. The retro-match process is intended to uncover such instances and inform the relevant parties.

PFs will need to have the proper procedures and integrations to ensure that all of this passing of information back and forth happens as required, within the established timeframes.

False positives

One common hurdle for PFs screening merchants against the MATCH system is the potential for false positives. PFs must balance the possibility of creating friction during the merchant application process against their need to gather enough information to conduct an accurate review of MATCH. Gathering too little information will increase the chances of false positives.

For example, if the business owner has a common name and the PF checks that name against the system, it could come back with a match – even if it isn’t the same merchant. In that case, the PF would be unable to board that merchant without obtaining further information to distinguish it from the merchant on the list.

So, while collecting a lot of information upfront is potentially burdensome to the merchant, it reduces the chance of false positives. The more information you have, the clearer it will be whether that merchant is indeed the one that appears on the MATCH list. PFs need to keep this balance in consideration as part of designing their onboarding process. While most want merchants to be able to go live as quickly as possible, collecting minimal information to make that