Context

In a fintech payments company processing 50M+ card transactions/day across multiple processors, you’re migrating from a legacy settlement system to a new warehouse model used for regulatory reporting (SOX), dispute operations, and revenue recognition. The migration requires dozens of field-level conversions: currency normalization, status code standardization, timestamp timezone rules, and PII handling. A single undocumented assumption (e.g., how to map a processor-specific decline code) can cause downstream metric drift, audit findings, or incorrect customer notifications.

Core question

How do you document conversion requirements and mapping rules for a SQL-based ETL/ELT pipeline so that engineers, analysts, and auditors can understand and validate the transformations?

Address the following:

1. Requirements capture: What information do you collect from stakeholders (finance, risk, ops) and from the source systems?
2. Source-to-target mapping spec: What columns/fields should a mapping document include (e.g., source field, target field, transformation logic, defaulting, null rules, data types, units, timezone, rounding, code mappings)?
3. Rule expression: How do you represent rules that are conditional (e.g., CASE WHEN) or depend on multiple fields/joins?
4. Edge cases & exceptions: How do you document unknown codes, late-arriving data, duplicate events, and conflicting sources of truth?
5. Validation & sign-off: What data quality checks, reconciliation queries, and acceptance criteria do you attach to each mapping?
6. Operationalization: How do you keep documentation in sync with SQL code (versioning, lineage, change management), and how do you make it discoverable?

Scope guidance (what the interviewer expects)

• A practical, repeatable approach (templates, data contracts, mapping tables, dbt-style docs, or a metadata catalog)
• Concrete examples of a mapping rule (e.g., status code normalization) and how it would be documented
• Trade-offs between “docs in a wiki” vs “docs as data” (tables + tests + generated docs)
• How your approach reduces ambiguity, supports audits, and prevents silent metric regressions

Source-to-Target Mapping Specification (S2T)

A structured document that enumerates every target field and defines where it comes from, how it’s transformed, and what constraints apply. In SQL-heavy environments, an S2T acts as the shared contract between upstream systems, transformation code, and downstream consumers.

Rules as Data (Mapping Tables)

Instead of hardcoding conversions in long CASE statements, store mappings (e.g., code -> standardized_code) in reference tables. This improves maintainability, enables non-engineer review, and makes changes auditable via table versioning.

SELECT t.txn_id,
       COALESCE(m.standard_status, 'UNKNOWN') AS standard_status
FROM raw_transactions t
LEFT JOIN status_code_map m
  ON t.processor = m.processor
 AND t.raw_status_code = m.raw_status_code;

Conditional Transformations with CASE WHEN

Many conversions depend on multiple fields (e.g., status + reason + channel). Document each condition, its precedence order, and the fallback behavior to avoid ambiguity and ensure deterministic outputs.

CASE
  WHEN t.is_chargeback = 1 THEN 'CHARGEBACK'
  WHEN t.raw_status IN ('S', 'SETTLED') THEN 'SETTLED'
  WHEN t.raw_status IN ('D', 'DECLINED') THEN 'DECLINED'
  ELSE 'UNKNOWN'
END AS standard_status

Embedded Validation & Reconciliation Queries

Each mapping rule should have explicit acceptance criteria and a query to validate it (counts, sums, null rates, uniqueness, referential integrity, and financial reconciliations). This prevents silent drift and supports auditability.

SELECT standard_status, COUNT(*)
FROM fact_transactions
WHERE txn_date = DATE '2026-02-01'
GROUP BY 1;

Lineage, Versioning, and Change Control

Documentation must be tied to code and data versions (Git SHAs, migration IDs, effective dates). When mappings change, you need a clear record of what changed, why, who approved it, and whether historical data was backfilled.