Pre-sub Validation

Anti-Fraud Lists and Pre-sub Validation

During pre-sub validation, each payment is validated against any anti-fraud list associated with the submission group. See the “Groups - Anti-Fraud Lists” help page for details on how anti-fraud lists are assigned to a group.

Disallowed List Example

The five items in the screen shot make up a disallowed list.

So none of the payments in a submission must appear on the disallowed list.

Assume the following payment: Account Name = MRS E SMITH Sort Code = 010004 Account Number = 10000003

This payment matches the first item in the disallowed list exactly even down to the title, initial and surname of the account name. So this would create a pre-sub validation message using the severity set at the group level. It would make sense for a disallowed list message to always create a “Fix” level message to force the user to investigate.

Now assume another payment: Account Name = TOM JONES Sort Code = 010004 Account Number = 10000054

This payment almost matches the fifth item in the list. The only difference is in the account name but the surnames match so this is considered “close enough” to warrant creating a pre-sub validation message.

Another payment has: Account Name = MR S NEWMAN Sort Code = 010004 Account Number = 10000046

This payment matches the sort code and account number of the fourth item in the disallowed list but doesn’t match the account name at all. It isn’t clear whether this payment is on the disallowed list or not. In this case a pre-sub validation message is created but it’s severity is reduced to a “Warning” regardless of the group level severity setting. This allows the user to decide whether this payment should be removed or not.

If the payment sort code and account number are not found on the disallowed list then the payment is considered to be good. For example: Account Name = MR J SMITH Sort Code = 010066 Account Number = 12300046

Cannot just match on the account name as there could be dozens of “Smiths” in a submission.

Allowed List Example

This time assume the five items in the screen shot above make up an allowed list.

A payment must appear on this allowed list to be considered a “good” payment.

Assume the following payment: Account Name = MRS E SMITH Sort Code = 010004 Account Number = 10000003

This payment matches the first item in the allowed list exactly even down to the title, initial and surname of the account name. So payment can definitely be considered a “good” payment and no pre-sub validation message needs to be created.

Now assume another payment: Account Name = TOM JONES Sort Code = 010004 Account Number = 10000054

This payment almost matches the fifth item in the list. The only difference is in the account name but the surnames match so this is considered “close enough” and no pre-sub validation message needs to be created.

Another payment has: Account Name = MR S NEWMAN Sort Code = 010004 Account Number = 10000046

This payment matches the sort code and account number of the fourth item in the allowed list but doesn’t match the account name at all. It isn’t clear whether this payment is on the disallowed list or not. In this case a pre-sub validation message is created but it’s severity is reduced to a “Warning” regardless of the group level severity setting. This allows the user to decide whether this payment should be removed or not.

If the payment sort code and account number are not found on the allowed list then the payment cannot be considered to be good. For example: Account Name = MR J SMITH Sort Code = 010066 Account Number = 12300046

In this case the account name is irrelevant as the bank details aren’t even on the allowed list so a pre-sub validation message must be created.