---
title: Operations and Control Model
description: Epara company-side risk, ledger, payout, provider, reconciliation, and audit operations.
---

# Operations and Control Model

Epara is not only a payment page for merchants. As the platform owner, the company must control money movement with accurate, auditable, and irreversible records. Operator Backoffice is therefore separated from Merchant Dashboard.

## Control desks

| Desk | Responsibility |
| --- | --- |
| Merchant Onboarding | KYB, agreement, business profile, capability, and go-live readiness. |
| Risk Desk | Payment, merchant, consumer, provider, and velocity risk review. |
| Payout Control | Merchant payout request, destination, schedule, and provider outcome. |
| Ledger Control | Double-entry ledger, balance projection, and no-negative-balance controls. |
| Reconciliation | Match provider/bank files against platform records. |
| Provider Operations | Provider health, route decision, credential, and operation retry management. |
| Webhook Control | Merchant endpoint, event delivery, retry, and signature evidence. |
| Audit Evidence | Permission checks, audit trail, immutable record, and hash evidence. |
| Compliance Control | KYC, KYB, agreement, financial limit, and policy enforcement. |
| Support | Consumer, merchant, and payment case management. |

## Maker-checker principle

Sensitive operations require separate requester and approver.

| Action | Maker | Checker |
| --- | --- | --- |
| Merchant live activation | Onboarding operator | Privileged operator |
| Payout approval | Payout operator | Finance approver |
| Risk hold release | Risk analyst | Risk approver |
| Pricing policy change | Product/finance operator | Governance approver |
| Provider credential rotation | Technical operator | Security approver |
| Balance adjustment | Finance operator | Finance approver |

## Ledger boundary

Operator UI must not make every screen look like it moves money. Some screens create evidence only and do not write Ledger.

| Operation | Creates Ledger movement? |
| --- | --- |
| Merchant onboarding review | No |
| KYB evidence upload | No |
| Webhook endpoint create | No |
| Provider route config change request | No |
| Payment capture | Yes |
| Refund success | Yes |
| Payout paid | Yes |
| Balance adjustment approved | Yes |
| Risk hold create/release | Usually no, but can affect availability |

## Risk decisions

Risk is not just "fraud or no fraud." Epara uses these outcomes:

| Decision | Meaning |
| --- | --- |
| allow | Operation can continue. |
| monitor | Operation continues with monitoring evidence. |
| review | Operator review is required. |
| hold | Money or capability is temporarily blocked. |
| block | Operation or capability is denied. |

## Provider route controls

Provider routing must consider:

- Provider health.
- Supported payment method.
- Currency, especially IQD.
- Merchant capability.
- Fee and settlement behavior.
- Provider credential state.
- Retry and fallback history.
- Risk or compliance restriction.

Every selection must be recorded as a `Provider Route Decision`.

## Reconciliation model

Reconciliation compares Epara ledger/payment records against provider, bank, or network files.

| State | Action |
| --- | --- |
| matched | Platform and provider records agree. |
| provider_missing | Epara has record but provider file does not. |
| platform_missing | Provider file has record but Epara does not. |
| amount_mismatch | Amount differs. |
| currency_mismatch | Currency differs. |
| duplicate | Same provider reference appears more than once. |
| unresolved | Manual investigation required. |

Reconciliation difference must not directly edit balances. If correction is needed, open a balance adjustment request with maker-checker approval.

## Audit evidence

Every serious action must answer:

| Question | Evidence |
| --- | --- |
| Who did it? | Actor id, role, session/device evidence. |
| Which permission allowed it? | Permission Check. |
| When did it happen? | Timestamp. |
| What changed? | Before/after or object state. |
| Why was it done? | Reason code, note, or linked case. |
| Did it affect money? | Ledger movement or explicit no-ledger evidence. |
| What happens on retry? | Idempotency result. |

## Live operations checklist

- Merchant onboarding and KYB are durable records.
- Live activation uses maker-checker.
- API credential secrets are never listed raw.
- Webhook delivery is signed and retryable.
- Payment capture, refund, and payout are idempotent.
- Ledger is double-entry and balanced.
- Reconciliation differences do not directly edit balances.
- Provider credentials are encrypted and rotatable.
- Operator action writes audit trail.
- Sensitive file access is tokenized and time-limited.