Athia Data Guidance
Understand the business data domains, quality expectations, and availability boundaries that shape Athia outcomes.
On this page
Athia works across payment, commerce, financial, risk, and operational information. This page explains those information domains and the qualities that make them useful. It is intentionally not a public schema, field catalog, or delivery contract.
Your DEUNA team confirms the source-specific mapping, required coverage, delivery mechanism, and validation rules during enablement. Existing source names can remain unchanged when their business meaning is clear and consistently mapped.
Data domains by use case#
The same broad payment context can support multiple Athia capabilities. Each use case depends on a different combination of business events, outcomes, timing, and financial evidence.
Coverage is use-case and source dependent. A connected processor, acquirer, warehouse, file, or API may contribute only part of the context required for a capability.
How to read this guidance#
- Think in business concepts. Athia needs a consistent meaning more than a specific source-system name.
- Keep source lineage. The origin, observation time, environment, and applicable merchant scope must remain traceable.
- Separate observed and derived information. Provider facts, merchant facts, and Athia classifications should not be presented as if they came from the same authority.
- Preserve relationships. Orders, payment attempts, retries, settlements, refunds, disputes, and operational actions must remain connectable without exposing sensitive credentials.
- Treat mappings as configuration. DEUNA and the merchant approve source mappings and validation during onboarding; this overview does not replace that agreement.
What makes a source useful#
| Quality | Why it matters |
|---|---|
| Complete enough for the objective | Missing business context limits which questions, recommendations, or decisions can be supported. |
| Consistent over time | A concept must retain the same meaning across files, providers, markets, and reporting periods. |
| Traceable to its source | Teams must be able to explain which system and observation supported an answer or action. |
| Timely for the decision | Authorization, settlement, dispute, and bank evidence become available at different points in the lifecycle. |
| Safe to use | Credentials and unnecessary sensitive data must stay outside reports, prompts, metadata, and free-text inputs. |
Availability and interpretation boundaries#
No source supplies every business concept at the same time. Athia reports the coverage and freshness it receives so the implementation team can decide whether another approved source is required.
An insight can be directionally useful with partial coverage, but an automated decision needs the agreed minimum context, policy, evaluation, and fallback. Financial views based on settled evidence will naturally lag real-time payment views; comparing them as if they represented the same observation window can be misleading.
Before production enablement, agree on:
- the business questions and decisions in scope;
- the approved source systems and merchant environments;
- the meaning and ownership of each mapped concept;
- acceptable completeness, freshness, and reconciliation thresholds;
- sensitive-data handling, access, retention, and deletion;
- the behavior when required context is late, incomplete, or unavailable.
Continue with Integrating Athia and Data governance for Payments Intelligence.