Credit Approval Workflow

Most credit limit changes on AEX go through an approval workflow to ensure that limit increases are reviewed before taking effect. This page explains the request lifecycle, who can act at each step, and how to manage requests in the UI.

Prerequisites

• To request a limit change: Credit.Manage permission on your entity
• To approve or reject a request: Credit.Manage permission on the counterparty entity (see below)
• To bypass the approval workflow: administrator status

Request states

A credit limit request moves through the following states:

State	Meaning
pending	Submitted and awaiting review
approved	Accepted — new limit is now active
rejected	Declined — original limit remains unchanged

Once a request reaches approved or rejected, it cannot be reversed or resubmitted. You must create a new request to change the limit again.

Who can approve

The approval requirement is cross-entity by design:

• The entity requesting the limit change cannot approve their own request
• The approver must be a user from the counterparty entity — the entity that would be the other side of the bilateral credit relationship

This separation ensures that no single entity can unilaterally increase their own credit exposure. The counterparty, who bears the risk of that exposure, must consent.

note

This means that to increase Entity A's limit with Entity B, a user from Entity B with Credit.Manage permission must approve the request.

Bypass approval

Administrators with bypass_approval permission can skip the workflow entirely. When a limit change is submitted with bypass approval, the new configuration takes effect immediately without requiring counterparty review.

This is intended for platform administrators managing emergency adjustments or initial configuration, not for routine limit management.

Workflow: request to resolution

1. Submit a request

1. Open Management Panel → Credit
2. Find the counterparty row in the Credit Limits table
3. Click the edit icon and configure the new limit parameters
4. Click Request Change

The request enters pending state. You will see it appear in the Pending Requests section at the top of the Credit panel.

2. Pending state in the UI

When you have pending requests, the Credit panel displays a collapsible pending requests banner showing:

• Number of pending requests
• Each request's counterparty name
• Status badge (colour-coded: amber for pending, green for approved, red for rejected)
• Time elapsed since submission

The counterparty's credit officers are notified of the incoming request through their own Credit panel, where it appears as a pending item awaiting their action.

3. Review and decide

The counterparty's credit officer reviews the proposed limit configuration. They can:

• Approve — the new limit takes effect immediately upon approval
• Reject — the original limit remains. A rejection reason can optionally be provided.

caution

Once approved, the new limit is active immediately. Ensure you review the proposed configuration carefully before approving.

4. Resolution

After approval or rejection, the request moves to its terminal state. The requesting entity's Credit panel reflects the outcome:

• If approved: the limit values update in the credit table
• If rejected: the original values remain; the request shows as rejected in the history

Next steps

• Credit System — limit types, scopes, and how credit checking works
• ISDA Documentation — documentation requirements that must be in place before trading