Advising financial crime teams: meetings, requirements and templates

1. 01First 10 minutes: decision or use case, consumers and current pain.
2. 02Next 10: source systems, population, grain and identity.
3. 03Next 10: history, latency, corrections and quality.
4. 04Next 10: access, retention, ownership and platform constraints.
5. 05Final 5: decisions, unresolved questions, owners and next deliverable.

Ask: “Show one record from origin to output.” This often exposes ambiguous keys and dates faster than discussing systems in general.

Avoid “data must be accurate” without a measurable rule and an authoritative comparison.

• Every eligible transaction remains represented, including unmatched exceptions.
• The timestamp boundary convention is explicit.
• No transaction receives multiple risk versions because of overlapping history.
• Missing identity or risk matches are reported with an agreed handling rule.
• Source, transformation and rule versions are traceable.
• Authorised and unauthorised access scenarios are tested.

As a financial crime analyst, I need the customer-risk version valid at the transaction time, so that historical analysis does not apply today's classification retrospectively.

For each field record: source object and column, business definition, source type, target field and type, transformation, NULL handling, key role, timezone, effective-time meaning, quality rule, classification and owner.

Example: source risk_code becomes risk_rating through a versioned reference mapping. Unknown codes are quarantined or explicitly represented under an approved rule. Do not map unknown to LOW as a technical default.

A proposal is not a decision until the responsible owner accepts it.

• Decision ID and date; status: proposed / accepted / superseded.
• Problem and context; options considered.
• Decision and rationale; tradeoffs, costs and risks.
• Security and data-quality implications; required evidence.
• Owner and approvers; review trigger.
• Links to requirements and mappings.

Worked decision: use half-open validity intervals with NULL for the open end. Benefit: unambiguous boundaries. Cost: consumers must use the documented as-of predicate. Evidence: boundary, overlap, late-arrival and replay tests.

Include a one-page business summary, conceptual model, physical flow, field mapping, identifier and history contract, access matrix, quality gates, operational objectives, migration implications and open decisions. Every unresolved item needs an owner and a due date.

Assess impact, urgency and reversibility. A wrong entity key or validity model can contaminate many products, so settle it before polishing dashboards. A naming issue may be easier to correct later. Keep an explicit decision log so teams do not repeatedly debate the same choice.

• Grain and authoritative source are unambiguous.
• Keys remain stable across loads and platforms.
• History, corrections and deletions are defined.
• Consumers know the limitations and excluded populations.
• Access controls apply to each copy and interface.
• Quality failures have an owner and a publication response.
• Recovery, cost and migration requirements are considered.
• Decisions and evidence are recorded.

A team requests “all customer data in the warehouse, refreshed in real time.” Respond with a clarified brief: which consumer decision needs which fields, what delay is tolerable, which population is eligible, what history is needed, who is authorised and what measurable benefit justifies the latency.