Skip to main content

Partner Whitelist

Purpose​

The partner whitelist is the allow-list that Issuance Step 1 validates against. It governs which partner entities and wallet addresses can receive token issuance, and bounds per-partner throughput via daily/weekly/monthly limits.

Every change to the whitelist — partner creation, wallet addition or removal, limit change, suspension, deactivation — is proposed by Customer Support and confirmed by the Compliance Officer.

Who Can Propose​

Customer Support. Treasury Officer may also propose for EMI-owned partner records (the EMI onboarded as its own partner for internal liquidity operations).

Trigger​

A new or existing partner sends updated details outside the backoffice, or there is a business need to update limits.

What happens before (partner communication, document collection) and after rejection (follow-up with the partner, resubmission) is outside this process.

Overview​

  1. Customer Support proposes a whitelist change — partner identity, wallet address(es), and limits — with supporting evidence
  2. Compliance Officer reviews, and confirms or rejects
  3. Backoffice commits the change atomically to the live whitelist on CO confirmation; a new version record is created with a pointer to the prior version

Constraints​

  • Compliance Office reviews KYB state at every whitelist change, not only at onboarding.
  • Every state change is versioned. The exact whitelist state at any past point can be reconstructed for audit, and every issuance request links to the whitelist version in force at creation time.

Change Types​

  • Partner creation — initial KYB, legal entity details, wallet addresses, limits.
  • Wallet add / remove — adding or removing a whitelisted wallet for an existing partner. Adding requires wallet-ownership attestation (see Step 1).
  • Limit change — updating daily, weekly, or monthly limits. New limits apply prospectively; in-flight issuance requests are evaluated against the limits in force at request creation.
  • Suspend — temporarily block new issuance for the partner. Reversible via a subsequent "unsuspend" change.
  • Deactivate — permanently remove the partner from active status. Not reversible; a fresh partner record is required to re-engage.

All change types follow the same Step 1 → Step 2 flow.

Steps​

Step 1 — Propose Change​

Owner: Customer Support · Status: new → awaiting_compliance_review

  • Customer Support creates a whitelist change record: change type, target partner (or new partner identity), proposed new state, supporting evidence references (KYB documents, partner correspondence, wallet-ownership attestation).
  • For wallet add changes: Customer Support records the partner's wallet-ownership attestation (signed message, small test transfer from the wallet, or equivalent — see Open Decisions).
  • For limit change changes: the proposed limits are recorded per period (daily, weekly, monthly). Unset means no limit for that period.

Step 2 — Compliance Review & Confirmation​

Owner: Compliance Officer · Status: awaiting_compliance_review → closed_applied or closed_rejected

  • CO reviews the change against: KYB, sanctions screening on the partner entity and any new wallet addresses, adverse media, and proportionality of proposed limits relative to KYB-declared expected activity.
  • Confirm → the change is applied atomically to the live whitelist. A new version record is created. The applied state takes effect immediately for subsequent issuance requests.
  • Reject → closed_rejected with documented rationale. No change applied. Customer Support handles follow-up with the partner outside this process.

End States​

StatusDescription
closed_appliedCO confirmed; change applied to the live whitelist and versioned.
closed_rejectedCO rejected with documented rationale. No change applied.

Limits​

Limits are optional per partner and configurable per period. A partner may have any combination of daily, weekly, and monthly limits, or none at all.

  • Daily — maximum cumulative mint volume for the partner in a 00:00 UTC – 23:59 UTC window.
  • Weekly — maximum cumulative mint volume in a Monday – Sunday window.
  • Monthly — maximum cumulative mint volume in a calendar month.
  • Unset — no cap for that period. Leaving all three unset is allowed but not recommended.

Calendar-anchored windows (rather than rolling) are easier to reason about, align with accounting periods, and make limit utilisation predictable across the operator UI.

Enforcement​

At Issuance Step 1, the backoffice computes the partner's remaining capacity for each configured period by summing the amounts of issuance requests that ended in closed_confirmed within the window. If the new request would push any configured period over its limit, the request is rejected at intake.

  • Limits are evaluated against the limit values in force at request creation time, so a mid-flight limit change does not retroactively invalidate an accepted request.
  • Limit utilisation is surfaced on the partner detail view and in issuance intake — the operator sees "X of Y remaining this period" before submitting.

SLAs​

ParameterValue
Compliance review windowTBD
End-to-end (happy path)TBD

Open Decisions​

DecisionNotes
Default limits on partner creationUncapped by default vs. a conservative starter cap.
Wallet-ownership attestation methodSigned message, small test transfer from the wallet (strongest), or in-person / video attestation (for high-value partners). Choice may differ between partners. For now deffered to Customer Support process outside of the Backoffice.