acilox / solutions / multi-source-finance-etl
๐Ÿฆ Data Engineering

Multi-Source Finance ETL

Daily financial ETL that pulls core banking, customer master, partner files, and FX rates into a Snowflake warehouse with fraud scoring, SCD-2 dimensions and SOX controls applied along the way.

0
Fraud rules evaluated per row
0
SOX controls enforced
$10K
High-value flag threshold
โ‰ฅ 3ฯƒ
Z-score anomaly bound

Why this exists

Financial institutions consolidate accounting and risk inputs from several upstream systems on a fixed schedule. The patterns are well known but tedious to get right: incremental extraction, multi-currency normalisation, rules-based fraud detection, slowly-changing dimension management, and data-quality gates ahead of the warehouse. This is the reference build a finance data team can lift wholesale.

How it's wired together

sources

Oracle
core banking (CDC)

Postgres
customer master

SFTP
partner files

FX rates API

raw landing
S3 / Parquet, hive partitioned

normalise
+ FX conversion
+ RFM segmentation

fraud rules
velocity ยท โ‰ฅ$10K ยท geo ยท zโ‰ฅ3ฯƒ

Redis fraud-alert stream

SOX controls
6 checks pre-load

SCD-2 MERGE
(Snowflake)

Snowflake warehouse
FACT_TRANSACTION ยท DIM_CUSTOMER

Great Expectations
DQ gate

downstream BI

Multi-Source Finance ETL architecture overview

How it works, end-to-end

  1. Incremental extraction across four sources

    Oracle (core banking) via CDC, Postgres (customer master) via Airbyte-style snapshot, SFTP partner files via inotify-on-arrival, FX rates from a REST API on a fixed schedule. All write to S3 as hive-partitioned Parquet.

  2. Multi-currency normalisation + RFM segmentation

    Transactions are normalised to a reporting currency using the close-of-day FX snapshot. Customers are RFM-scored (recency, frequency, monetary) for downstream segmentation.

  3. Rules-based fraud scoring

    Four rules run per row โ€” velocity (transaction count per window), high-value flag (โ‰ฅ $10K), geo-velocity (impossible-travel), and z-score outlier (โ‰ฅ 3ฯƒ rolling). Hits land in a Redis fraud-alert stream for real-time consumers and a fact table for analytics.

  4. SCD-2 dimensions via Snowflake MERGE

    Six SOX controls evaluated pre-load โ€” completeness, freshness, referential integrity, primary-key uniqueness, range, sum-check. SCD-2 MERGE writes versioned dimension history.

  5. Great Expectations data-quality gates

    GE suite runs post-transform with fail-fast on critical expectations. A second pre-normalisation pass catches malformed currency codes before the cost of FX conversion is paid.

The choices that matter

Decision

SCD-2 via Snowflake MERGE, not delete-and-reload

Versioned dimension history lets every downstream report be reproduced as-of any prior date. The MERGE pattern is durable across schema changes; delete-and-reload silently destroys history.

Decision

Fraud z-score uses an in-memory rolling window

Simple, fast, no extra infra. Sufficient for single-worker setups and dev environments.

Multi-worker deployments must move the window to Redis sorted sets โ€” flagged in the README, swap-only change to the rule implementation.

Decision

SFTP polling, with event-driven swap path

Universal compatibility with partner SFTPs. inotify-on-arrival is wired where the partner supports a notification push; the rest poll on a 5-minute cadence.

A 5-minute floor on partner file latency. Acceptable for batch consumers.

Decision

GE runs post-transform, with a pre-normalisation hook

Catching dirty currency codes after FX conversion wastes compute. The pre-pass is cheaper and prevents the failure mode that costs the most.

Built on

Python 3.11SnowflakeOracle CDCAirflow 2.xPostgresRedisGreat ExpectationsParquetS3SFTP