Skip to main content
All systems operationalChangelogv1
Log in

Source Mapping Guidance

Understand how DEUNA aligns merchant and provider data to Athia without publishing a universal field contract.

On this page

Athia connects business concepts across commerce, payment, financial, risk, and operational sources. The mapping for a specific deployment is agreed privately during enablement; this page describes the approach, not a public schema or a list of required fields.

Conceptual information domains#

Commerce contextThe order or business event, its value, market, channel, customer journey, and commercial outcome.Payment lifecycleThe attempts, decisions, provider outcomes, retries, authentication, and post-transaction operations.Instrument contextApproved, minimized information that distinguishes a payment method or reusable credential without exposing secrets.Financial movementSettlement, payout, fee, refund, dispute, and bank evidence used to explain what moved and why.Risk and disputesApproved decision, review, fraud, case, evidence, and outcome context needed by the enabled use case.Operational lineageThe source, observation time, environment, merchant scope, and transformation history behind each concept.

These domains are intentionally broad. A capability may use only part of a domain, and the authoritative system can differ by merchant, provider, market, and stage of the lifecycle.

How source mapping works#

01 · define
Agree on the objective
Define the business question, decision, KPI, and permitted action.
02 · inventory
Identify approved sources
Locate the systems that authoritatively observe each required concept.
03 · map
Align business meaning
Agree on meaning, grain, relationships, timing, ownership, and permitted transformations.
04 · validate
Measure coverage and quality
Test completeness, consistency, freshness, lineage, and safe handling.
05 · operate
Monitor the mapping
Detect source drift, late delivery, definition changes, and coverage loss.

One merchant concept may be represented differently across a processor report, warehouse model, API, or file. DEUNA does not require those sources to adopt a public canonical name. The approved mapping records how each source contributes to the deployment and which system remains authoritative.

Mapping principles#

PrincipleImplementation guidance
Meaning before namingAlign the business definition rather than renaming source columns to resemble an example.
Preserve grainKeep order-level, attempt-level, event-level, case-level, and financial evidence distinguishable.
Retain authorityRecord which source owns an observation and which values are derived.
Keep relationships stablePreserve durable, non-sensitive links across the lifecycle so outcomes can be explained.
Make time explicitRetain observation, processing, and financial availability boundaries where they differ.
Minimize sensitive dataShare only the approved context needed for the enabled objective; never include credentials in free text or metadata.
Treat change as versionedReview mapping changes before a source or business definition reaches production.

Readiness gates#

Before a mapping supports production insights or decisions, the merchant and DEUNA agree on:

  1. the use case, merchant scope, markets, environments, and evaluation period;
  2. the approved sources and authority for each business concept;
  3. the expected grain, lifecycle relationships, and timing boundaries;
  4. quality, freshness, reconciliation, and drift thresholds;
  5. access, retention, minimization, deletion, and audit requirements;
  6. fallback behavior when an approved source is incomplete, late, or unavailable.

The resulting mapping is deployment-specific configuration maintained with your DEUNA team. It is not inferred from this documentation.

Continue with Athia Data Guidance, Integrating Athia, and Data governance for Payments Intelligence.