Rollover

Understanding the period numbers in the logs

It is possible to reconstruct the actual period timestamp from the period numbers that are in the logs. For daily calendars, multiply the period number by the number of seconds per day:

The formula is:

Convert the resulting UNIX timestamp by using an epoch converter to get Thursday, 6. December 2018 00:00:00. For calendar periods other than daily you have to multiple by the number of days per period, for example, 7 for weekly, 31 for monthly, and so on.

Case examples

What happens when a transaction arrives with a timestamp that is older than the oldest period of a calendar, for example, when a daily calendar has three periods, but the transaction has a timestamp of five days ago?

There is no period to be updated. This transaction will not have any influence on the calendar outputs. The calculated value for this period will be 0. For more information, see Calendar outputs in transaction query results.

Why does my calendar roll over, although the transaction that triggered the rollover does not fulfill the calendar’s computation condition?

The calendar’s Computation conditions would be more aptly named Update conditions. They determine only if periods in the calendar are updated. The rollover is run regardless of the Computation conditions of the calendar. However, a period update still does not occur if the conditions are not fulfilled.

I have an index on the account number and a calendar that counts the frequency and amounts on these accounts. Is the rollover applied to the periods of all accounts?

Yes, the periods of all accounts (all index nodes) are affected. IBM Safer Payments stores a global most recent period for every calendar.

Are all my calendars affected by a rollover?

As explained earlier, the rollover is applied to all evaluated calendars regardless of the calendar’s computation conditions. However, calendars can refer to different timestamps that determine the calendar’s periods (by using the Timestamp setting). When a daily calendar CAL1 uses the system time as the decisive timestamp, and a second calendar CAL2 uses the transaction timestamp at the point of sale (POS), which will typically be a date in the past, only CAL1 is affected by the rollover that is triggered naturally on the next day. CAL2 uses the POS timestamp to determine its periods and a potential rollover. The answer to the question is, therefore, that all evaluated calendars that use the same timestamp attribute are affected by a rollover.

Where rollovers can be dangerous

Depending on the payment type and context, there are various possibilities to define what the timestamp of a transaction is. Some clients have a POS timestamp, in other channels we see execution date or payment date which leaves space for interpretation what this timestamp is. While a POS timestamp is certainly always in the past (relative to the time that IBM Safer Payments receives the transaction for processing, even though it might be just a few milliseconds in a real-time processing), an execution date can also be in the far future for scheduled wire transfers. If such a transaction arrives in IBM Safer Payments, it has the potential to lead to unexpected results in all calendars. All evaluated calendars that have the same timestamp attribute will rollover to the future date, discarding values of past periods. There is also the risk of incorrectly formatted input data which might translate to timestamps like 2478-03-23 13:11:23. It is a best practice to catch and handle both expected and unexpected future timestamps.

Handle expected future timestamps

If future timestamps (scheduled wire transfers) are expected, reevaluate if the timestamp attribute that is used as a transaction timestamp is really appropriate. Consider the following questions:

1. Is a transaction that will be executed in the future relevant for my profiles and rules?
2. If scheduled transfers are part of a fraud pattern, wouldn’t it be better to be able to explicitly identify and treat them with dedicated rules and profiles?
3. How do I want to handle a situation where a scheduled transfer is canceled? Is IBM Safer Payments even receiving this information?
4. Information about scheduled payments is of no value for me. I would rather receive a transaction record when the transaction is actually executed.

Raising the number of periods for the calendars to be able to hold the values for all of the periods between your current date and the maximum possible future date is probably not satisfactory. Period 0 in the calendar output definition will always return the outputs for the most recent timestamp of the configured timestamp attribute, which is not the value you would typically expect when treating a current transaction.

If scheduled transfers need to be kept in the data, a possible solution could be to add an additional timestamp attribute scheduled date for these cases and redefine the execution date as the date when the transaction has been created. This allows to differentiate scheduled transactions in calendars, rules, etc, and will prevent unwanted rollovers. You can also leverage preprocessing rules in IBM Safer Payments 5.7 to achieve this. For more information and an example, see Handle unexpected future timestamps.

Handle unexpected future timestamps

Even if future timestamps are not expected, sometimes there are problems with the data source and the formatting of timestamps in the source data, as explained earlier. There are two ways to handle these unexpected future timestamps:

1. In versions prior to 5.7, where preprocessing rules are not available, we can stop calendars from being evaluated by using index computation conditions (SystemTime is less than (TransactionTimestamp – Threshold)). Unfulfilled index conditions prevent all calendars that are bound to this index from being evaluated, and therefore also prevent them from rolling over. As a negative side effect, all other features connected to an index, like counters, precendents, masterdata, and so on, won’t return any results for this transaction. However, if such an important attribute like the timestamp is broken, how to treat the transaction?
2. To overcome the limitations, preprocessing rules can be used. Preprocessing rules work like normal rules, but they are executed before the index and calendar evaluation. They have been available since IBM Safer Payments 5.7. The same condition that was used above, can be used in a preprocessing rule to then fix the timestamp in the conclusion, for example, setting the transaction timestamp to the SystemTime. Then, the transaction is treated like any other.