Data governance for Payments Intelligence
Define data access, isolation, model use, retention, action authority, and audit requirements before enabling Athia or specialized agents.
On this page
Payments Intelligence and Agentic Optimization depend on merchant-authorized data and connections. Before production enablement, document what DEUNA can access, what each user and agent can do, how long data is retained, and which actions require human authority.
Establish the data boundary#
| Question | Required decision |
|---|---|
| What data enters Athia? | Approve each processor, acquirer, warehouse, file, API, order, settlement, dispute, and internal-system source. |
| Which fields are necessary? | Map only fields needed for the approved use cases and apply the classifications in the Athia Data Dictionary. |
| Who can access the result? | Assign roles by merchant, environment, workspace, data source, and action authority. |
| What can leave the platform? | Define export, report, alert, API, and workflow destinations before enabling them. |
| How long is data retained? | Record the contractual retention and deletion policy for raw inputs, normalized records, outputs, traces, and audit events. |
| Where is data processed? | Confirm the contracted processing region, transfer mechanism, and relevant subprocessors. |
Do not send a full PAN, CVV, authentication secret, or provider credential through a report, prompt, free-text field, or workflow input. Follow the field-level data class and use a stable pseudonymous identifier when the analysis does not require direct identity.
Separate connection credentials from agent context#
Connections must keep secrets in the platform's credential boundary. Agents and prompts should receive only approved tool results and normalized fields, never the underlying API key, password, private key, or file-transfer credential.
When a source supports scopes, grant the minimum set that still provides the approved use case. A read connection does not grant permission to execute a payment, change routing, submit a dispute, or modify a provider account.
Define model-use terms explicitly#
Do not infer model-training rights from product access. The applicable agreement must state whether merchant data can be used for account-specific tuning, evaluation, aggregated intelligence, or any other model improvement. Public documentation does not expand those contractual rights.
At minimum, record:
- the model or model class used for each capability;
- whether merchant inputs or outputs are retained by a model provider;
- whether data contributes to shared or account-specific improvement;
- the evaluation and approval required before a model version receives production traffic;
- the rollback and incident process when quality or safety falls below the agreed boundary.
Bound every action#
An agent must not gain a capability merely because the underlying connection can perform it. Define allowed tools, environments, providers, markets, methods, amounts, traffic shares, timeouts, and approval thresholds independently.
Preserve evidence and accountability#
Retain enough evidence to answer:
- which source data and version supported an answer or decision;
- which agent, workflow, model, policy, and tool version ran;
- whether a human approved, rejected, or changed the proposed action;
- what request reached an external system and what that system confirmed;
- which outcome was measured and whether it triggered rollback or escalation.
Use Activity Logs for supported administrative changes and the Athia workflow and model traces described in Agentic Workflows and Model Training and Testing.
Security and privacy evidence#
Certification scope, security controls, privacy terms, and current assurance material are maintained through DEUNA's Trust Site. Confirm data residency, retention, deletion, incident notification, and subprocessor requirements during onboarding; certification badges alone do not define those account-specific obligations.