Personalization
If you want to customize the output of the Ntropy API you can do so by defining a ruleset through the
personalization API in /v3/rules/
.
A ruleset is a set of rules that change some of the fields returned by the enrichment API, such as entity attributes or adding and removing labels. If not specified otherwise, rules are applied to all transactions. Rulesets are unique per API key.
In order to apply them to a subset of transactions, you can filter by the values that transaction fields of
this set would have. To apply to consumer or business transactions you could use account_holder_type
. To have more
fine-grained control and apply it to specific account holders or subsets thereof
please see this example.
Rules
There are two types of rules: actions and conditionals. Actions are used to change the fields of transactions. Conditionals, execute actions depending on a boolean expression. To replace the logo of a website, we could use:
Please refer to our examples section for more examples on how to override labels in the enrichment result or how to segment rules by account holders or by subsets of their accounts.
Uploading and modifying rulesets
Rulesets are type checked when modified. They can be uploaded, replacing all of the existing ones via POST request to
/v3/rules/replace
.
and retrieved by a GET request to the /v3/rules
.
Only one ruleset is allowed per API key.
To add rules to a ruleset, you can do it via a POST request to
/v3/rules
.
Deleting and replacing individual rules can be done via
DELETE /v3/rules/{id}
.
and PATCH /v3/rules/{id}
.
respectively.
There is a size limit of 200,000 bytes for API key rulesets which is enough for approximately 8000 basic rules.
Rule Specification
Actions
There are 3 types of actions a rule can perform. They take expressions as arguments and can set general properties, modify labels and modify mccs.
Set property
Modify labels
You can add labels, remove labels, or replace all the labels. These expect strings.
Modify MCCs
Similarly, you can add, removes, or replace all the MCCs. These expect numbers.
Conditionals
Execute a set of actions if condition
is true. A condition is an expression that evaluates to a boolean.
Note that conditionals support the specification of rules in the then
clause. This means that nested conditionals
are supported. Building on the previous example:
Expressions
Expressions can have one of three types: number, boolean, or string. null
is not an allowed value.
All numbers are interpreted as floats.
Expressions can be literals, transformations or operators.
Transformations
There are currently 7 transformations supported:
Operators
Operators evaluate to a boolean literal and take an arbitrary number of arguments and are evaluated as
((arg1 <op> arg2) <op> arg3) <op> ...
:
Properties
Each property corresponds to an enrichment transaction field of the same name
. write
and read
indicate whether
the property is writable and/or readable.
Examples
Adding income label to interest payments
Account holder rule segmentation
For further control over the subset of transactions rules apply to, if you only want to apply a set of
rules to an account holder ntropy
, you can use the property account_holder_id
to do so:
Taking this a step further, there are some use-cases where instead of applying rules to specific account holders, you may want to apply it to all future account holders that follow a specific pattern.
This could simplify the
management of rules and account holder management on your side. To this end, you can use a combination of starts_with
and account_holder_id
. For example, if for every account under the account holder ntropy
we want to apply a set of
rules, we could adopt the naming convention of ntropy_<specific_id>
and set rules of this form: