All modules
FoundationModule 01Week 1

Start here: role, 12-week plan and first 30 days

Read the lesson, apply the exercise, then capture your evidence. This module defines the role, the twelve-week path and the first 30 days at work.

01What success looks like

You can turn a vague request from a financial crime team into a defined data product: its purpose, grain, sources, identifiers, history rules, permissions, quality checks and acceptance evidence. You can challenge a design with evidence and work with engineers to implement it. Reading this course alone does not qualify someone to approve production architecture.

Your Corporate Actions experience already gives you useful habits: reconcile populations, distinguish event dates, trace an outcome back to a message, handle exceptions and retain evidence. The new skill is expressing those controls as data contracts, models and repeatable tests.

02The learning sequence

Suggested weekly pattern: two hours reading, three hours exercises, one hour explaining your work to someone, and up to two hours revising. Extend the programme if SQL is entirely new to you.

WeekStudy and practiceEvidence to produce
1Module 02: systems, tables, grain, keysExplain one dataset and draw its source-to-consumer flow
2Module 03: SELECT, filtering, grouping, NULLComplete SQL exercises 1 to 4
3Joins, windows, reconciliation; Module 04 HueExplain and fix a duplicated transaction total
4Module 05: AWS and cloud boundariesAnnotated architecture with access boundaries
5Module 06: SnowflakeSource-to-target mapping and dialect checklist
6Module 07: GUID, hashes and valid-time historyHistory timeline and boundary test results
7Module 08: pipeline reliability and qualityData contract and exception report
8Module 09: two migration tracksMigration wave plan and rollback conditions
9Module 10: financial crime controlsEvidence-backed control assessment
10Module 11: advising other teamsArchitecture decision record and review pack
11Module 12: knowledge agent and sourcesApproved source collection and evaluation results
12Module 13: capstoneDefend the complete design to a colleague

03First 30 days at work

  1. 01Obtain the complete job description and agree the first deliverable with your manager.
  2. 02Confirm the boundary between business analysis, architecture and engineering.
  3. 03Confirm what your internal platform names and acronyms actually mean locally.
  4. 04Record the actual query engines and versions you connect to, such as Hive or Impala.
  5. 05Ask which analytical platform is hosted where, and what remains outside it.
  6. 06Obtain approved read-only access, a sandbox and the relevant data catalogue.
  7. 07Read one existing approved architecture decision and one source-to-target mapping.
  8. 08Shadow a data incident and a design review.
  9. 09Deliver one small, reviewed profiling exercise.

04Questions you must resolve internally

These questions have no universal answers. Resolve them with the responsible owners and write the answers down.

  • Who owns each dataset? What is its authoritative source?
  • Is the GUID an entity key or a row-version key?
  • Which exact columns enter DataHash and DeltaHash?
  • Are effective dates business dates or ingestion timestamps?
  • Are finish boundaries inclusive or exclusive?
  • How are source deletions represented?
  • What is the authoritative timezone?
  • What are the freshness, retention and recovery requirements?

05How to use the references

Each module links official text documentation. Read the selected section before branching into the full manual. Product features must be checked against the deployed version and account configuration.

The source register includes an agent ingestion workflow; links alone do not populate a knowledge agent.

06Self-assessment

Score each skill from 0 to 3: 0 = unfamiliar, 1 = explain with notes, 2 = complete a reviewed exercise, 3 = independently apply and defend. Track SQL, modelling, historisation, cloud, migration, controls and stakeholder advice. Aim for level 2 across all areas before taking an independent design assignment.

Financial Crime Data Architecture

A practical learning programme for analysts moving into financial crime data architecture and business analysis.

Quick start

Scope & assumptions

All labs use fictional data. Internal standards and approved platform configurations take precedence over illustrative design choices. Progress is demonstrated through deliverables and worked exercises, not reading alone.

Financial Crime Data Architecture — Training AcademyRead the lesson · Apply the exercise · Capture your evidence