Bank Filtering

Service Overview

The Bank filtering service offers means to filter the transactions based on criteria defined through dynamically configurable rules. The rules can be configured using the Dynamic Process Settings solution on IPF. This enables the rules to be updated without needing a restart of your IPF implementation.

To know more on why client implementations may want to consider using bank filtering service, please refer Why Bank Filtering?

The filtering service accepts selective payment attributes through the Bank Filtering Service API. The attributes can be populated by client implementation flows using available data to evaluate if the transaction being processed matches with any active filtering rules defined. The Service API provides a response based on matching rules and also provides relevant information about the rule(s), primarily the severity of the matching rule(s).

The Bank Filtering Service API response requires client implementations to determine how the payment should be processed based on the rules it has matched, if any. E.g:

Block / reject payment
Send the payment for manual review
Log the payment for regulatory reporting

Bank Filtering Contextual Diagram

Bank filtering services uses the below key components to provide client implementations the filtering capability.

Contextual Diagram

Components

Component / Feature	Description
Bank Filtering Rules	These are the filtering rules defined by client implementations for use in processing flows. The service also caches rules to improve the performance of the service.
Dynamic Processing Setting Management APIs	The setting management APIs are provided through IPF Dynamic Processing Settings. The APIs provide the ability to dynamically create, update and delete the rules as required. The DPS implementation also provides an optional approvals workflow so the rules can go through multi-eye approval checks before they are considered active.
Bank Filtering Service API	The service API provides an interface for client implementation flows / systems to interact with Bank Filtering service and retrieve the severity of the rules that match the provided input criteria. The Service API is versioned to ensure previous versions can be kept backward compatible in cases where the service functionality is extended based on future client requirements.
Bank Filtering logic	The logic provides the core filtering capability. It uses the dynamically configurable rules to ensure only active rules are applied as long as they match the input criteria and returns the highest severity associated with the payment when multiple rules match.

Component / Feature

Description

Bank Filtering Rules

These are the filtering rules defined by client implementations for use in processing flows. The service also caches rules to improve the performance of the service.

Dynamic Processing Setting Management APIs

The setting management APIs are provided through IPF Dynamic Processing Settings. The APIs provide the ability to dynamically create, update and delete the rules as required. The DPS implementation also provides an optional approvals workflow so the rules can go through multi-eye approval checks before they are considered active.

Bank Filtering Service API

The service API provides an interface for client implementation flows / systems to interact with Bank Filtering service and retrieve the severity of the rules that match the provided input criteria. The Service API is versioned to ensure previous versions can be kept backward compatible in cases where the service functionality is extended based on future client requirements.

Bank Filtering logic

The logic provides the core filtering capability. It uses the dynamically configurable rules to ensure only active rules are applied as long as they match the input criteria and returns the highest severity associated with the payment when multiple rules match.

Sample Usage

The below diagram shows a representative sample usage of the Bank Filtering Service API by a payment processing flow.

The sample flow maps the attributes from the payment being processed into the service API request parameters to retrieve the risk associated with the payment.

The flow takes below actions based on the risk values returned:

Highest Risk Severity	Rules Matched	Action
0	No rules matched	Payment can be processed further to carry out any more validations as needed before being submitted for clearing and settlement or account posting.
1 to 5	The payment matched one or more filtering rules but the rules are not business critical severity.	The payment will be routed for manual review for a human intervention to ensure it is safe to be processed and be rejected if needed.
6 to 9	The payment matched one or more filtering rules and the rules are of business critical severity.	The payment will be rejected / blocked to avoid the risk associated with the payment from materializing.

Highest Risk Severity

Rules Matched

Action

No rules matched

Payment can be processed further to carry out any more validations as needed before being submitted for clearing and settlement or account posting.

1 to 5

The payment matched one or more filtering rules but the rules are not business critical severity.

The payment will be routed for manual review for a human intervention to ensure it is safe to be processed and be rejected if needed.

6 to 9

The payment matched one or more filtering rules and the rules are of business critical severity.

The payment will be rejected / blocked to avoid the risk associated with the payment from materializing.

The attributes that should be mapped in the service API request, the range of severities to be used and associated actions with each severity are client implementation decisions.