Architecture

At the moment, the Transactions FeatureStore is used to serve anti-Fraud rules and checks in the transactions Cloud Function/Anti-Fraud service. The setup for how Transactions entity types will be pushed to the FeatureStore is executed as a synchronous process.

More details on the above architecture can be found here: Technical Specs: Anti-Fraud Rules

Ingestion: Historical Features Type

At the moment, most of the Fraud Rules are highly dependent on historical features calculations and historical data of a given customer’s transaction. As such, we need to establish these features' definitions.

We can break up historical features into 2 generic subsets.

  1. Inter-day

  2. Intra-day

Historical Feature Type

Description

Ingestion Method

Inter-day

Features that are dependent on calculations that exceed the day today. For instance, last 3 days, last 7 days, etc.

  • These features will be calculated from BigQuery and ingested as a nightly batch job into the FeatureStore

  • These features are then read from the online FeatureStore at point of calculation

Intra-day

Features that are dependent on intra-day calculations and within 24 hours from 0000 to 2359

  • These features will be calculated from AlloyDB/BigQuery on the fly

  • Following which, they are may or may not be ingested back into the Online FeatureStore

Cards & Transactions FeatureStore

This section details the overview regarding the Cards and Transactions FeatureStore

In essence, the FeatureStore will not contain the latest snapshot of a customer’s transaction history. The FeatureStore does not aim to be the most updated snapshot of a transaction history. Instead, it is meant to indicate the latest set of features that was used in the latest transaction decision made.

Therefore, with Transactions as an example, the trigger and update steps are as follow:

  • User makes a transaction

  • Transaction is sent to Slacker → Triggers Anti-Fraud Service for Transactions (Cloud Function)

  • Service reads the latest snapshot from either BigQuery or AlloyDB

  • Service returns a 200 response to Slacker, if valid

  • Service also writes this “latest” snapshot to the FeatureStore

As such, the FeatureStore will only contain the most updated set of historical Transaction values, that is accurate up till the time the latest transaction was made. This is to not only prevent flooding of the FeatureStore with continuous updates, but to also align across all business units the on what the last set of features that was used for decisioning are.

_snapshot_snapshot_v1` ORDER BY transactionType