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.
Inter-day
Intra-day
Historical Feature Type | Description | Ingestion Method |
---|---|---|
| Features that are dependent on calculations that exceed the day today. For instance, last 3 days, last 7 days, etc. |
|
| Features that are dependent on intra-day calculations and within 24 hours from 0000 to 2359 |
|
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