Calendar configuration

Calendars are configured on Model > Profiling > Calendars.

Calendar settings that are not listed below are explained either in the online help or elsewhere in this chapter.

Name

The name of the calendar is used only to show the calendar in the list of calendars. The calendar’s name is not selectable or visible anywhere in modelling. Multiple different outputs can be created in a calendar, so the name of the calendar is typically more general than the names of the particular output attributes. The name of the calendar should reflect the general calendar settings. For example, if a calendar is configured with 31 daily periods, the name of the calendar might be Daily calendar 1 month. However, the recommended convention for calendar names is:

  • Cal_{IndexName}_{daily/weekly/monthly/…}_{Conditions}

If you follow this convention, the name of the calendar in the previous example would be:

  • Cal_AccountIndex_monthly

Depending on the configuration of the calendar outputs, an example for an output name might then be Total amounts last 7 days (periods 0~6), Number of transactions yesterday (periods: 1), and so on.

The recommended convention for calendar output names is:

  • Cal_{IndexName}_{PeriodDescription}_{TotAmount|Freq}

If you follow this convention, the name of the calendar outputs in the previous example would be:

  • CAL_AccountIndex_Last7days_TotAmount and
  • CAL_AccountIndex_Yesterday_Freq
Index
Calendars are stored in the index storage layer. The index nodes in the index storage layer are stored in a balanced tree. IBM® Safer Payments always connects masterdata, calendars, device identification information, and events to an index node. If an index for the account number is configured, we will store calendar values per account. In case we have an index on the IP address of a device, the calendar values are stored for each of the IP addresses. Therefore, the selected index determines the dimension the calendar values are stored for.
Timestamp

This setting allows to select two different values:

  1. Reference timestamp

    In every configuration one input attribute must be onfigured with the timestamp meta attribute. This input attribute is considered as the timestamp of a transaction. When Reference timestamp is chosen, the value of this meta input attribute is used to update the calendar periods and to do rollovers if necessary. The important piece is, how different the computation of calendar outputs works, compared to the use other setting: Period 0 of the past periods of a calendar output will always refer to the most recent timestamp (reference timestamp) that has been ever seen by IBM Safer Payments in the timestamp meta attribute. For more information, see Reference timestamp in ddc_status.iris file.

  2. User other

    If filling and updating the periods has to be based on a different timestamp of the transaction than the timestamp meta attribute, use other allows to select a different input attribute of type timestamp. As previously mentioned, the difference lies in the computation of the calendar’s output attributes. When use other is selected, period 0 of the past periods of a calendar output always refers to the selected timestamp of the currently processed transaction.

Reference timestamp in ddc_status.iris file

The reference timestamp (most recent timestamp value of the timestamp meta attribute) is stored in the ddc_status.iris file in the ddc folder. The timestamp is saved as a 64bit integer, thus the last 8 bytes in the file store the value. The timestamp can be read with the following command:

od -tu8 -j8 ddc/ddc_status.iris
You can run:
date -d @1546516800

This produces the following output:


0000010 1546516800
0000020

You can run:


date -d @1546516800

To convert the Unix timestamp to a human readable date:

Thu Jan 3 13:00:00 CET 2019

In case

  • there are calendars with the Reference timestamp setting AND
  • to fix an unwanted rollover in calendars the timestamp meta attribute of existing transactions have been fixed using merging AND
  • the Rebuild index maintenance function has been used to fix the calendar periods AND
  • the actual most recent timestamp is lower than the reference timestamp,

Also, the reference timestamp has to be adjusted manually so that it generates correct outputs for period 0. A restart is necessary for changes to take effect.

Update during merging

IBM Safer Paymentswill update calendars that have this setting activated after a successful merge. The computation conditions of the calendar will be tested against the merge target transactions before and after the merge:

  • If a transaction did not fulfill the conditions before the merge but fulfills them after the merge, the respective period values are updated, for example, add amount, add frequency, recalculate standard deviation.
  • If a transaction fulfilled the conditions before the merge, but does not fulfill them after the merge, the respective period values are updated, for example, subtract amount, subtract frequency, recalculate standard deviation
  • If a transaction fulfilled the conditions before the merge and still fulfills them after the merge, the amount is adjusted, if it changed.

These are the only cases that are currently covered. More specifically, there is no mechanism to update values across periods, if, for example, the timestamp of the transaction changed.

Update after manual fraud mark

The Update calendar profiles and events by manual fraud mark setting is on Administration > System configuration > Investigation & Queries. While Update during merging requires an actual incoming message to trigger the update process, a manual fraud mark is executed in the user interface. If calendars use the fraud flag in their conditions, this setting should be activated to update them.