Matching Rules
Last updated
Last updated
Matching rules define relationships between two transaction sets from one or two sources. They are applied after data was ingested, and identify matches based on specific criteria. Rules are logically directional, they assume a relation of causality or timing between transactions. The two sides are referred to as origin and target.
Each rule includes audience filters and matching logic:
Audience Filters: Audience filters are applied to transactions from the origin and target independently. They select only the transactions that meet specific criteria.
Matching Logic: Once the audience filters have narrowed down the relevant transactions from both sources, the matching logic compares them individually to determine if they are related.
Matching Rules are logically directional, with the direction signifying causality or timing. However, this does not imply any requirements on the order in which data comes is ingested. Data is evaluated against rules regardless of when it was ingested.
New data coming in is evaluated against all rules. Records that pass the audience filter will be evaluated against records from the other Source in the rule. If the matching logic applies, a Match will be created. A single rule can generate multiple matches for each transaction (essentially creating a many-to-one, one-to-many, or many-to-many relationship from multiple one-to-one relationships), and two transactions may match via multiple Matching Rules (with multiple separate matches). By default, all rules will be evaluated simultaneously, and can also generate multiple matches. This behavior can be overridden by setting up a hierarchy. A hierarchy determines that rules are executed one by one, and only the first one to apply will create a match
Matching Rules can be set up as an aggregation, where the one-to-many or many-to-one relationship is inherent. In most such cases the comparison should to be reflected in the amount. This type of match is very common for batch settlements, where many transactions are settled together, and the amount of the settlement is expected to equal exactly the total amount of the transactions. Additionally, since in some cases the settlement schedule is not well-defined, Matching Rules can be configured to attempt to match against multiple groups, to find the right match.
Example
A credit card issuer settles daily from their FBO bank account on J.P. MorganChase to Visa (the network). The aggregation rule is set up such that the sum of all origin transactions (processed purchases) add up to the amount settled out of the FBO account (ACH pull) the next day. In some cases the pull is done in delay, this could be due to a bank holiday, or due to any other issue on either side of the transaction. This means that the matching based on the difference in days (e.g. expecting a settlement “the next day”) might not be stable. The solution would be matching the settlement against each of the daily aggregations, to find the accurate match.
In some cases, a transaction from one Source could match against an unknown subset of transactions from another Source. This is a challenge because the number of possible subsets grows exponentially with the number of transactions: at 5 transactions, there are 32 possible subsets, but at 20 there are over a million. Ledge solves this problem heuristically and efficiently and in most cases can find the correct subset based on accurate amount.
Some scenarios may result in duplicate matches. As an oversimplified example, if a customer has three open invoices for $100, and has made three payments for $100, it’s hard to tell which payment applies to which invoice. Users may set up de-duplication to determine which invoice should be matched to which payment. It can be based on FIFO/LIFO (first/last in - first out) strategy, or on other arbitrary logic. De-duplication is executed after the match was created, and can take into account all other matches.
