Introduction

Counterparty approvals ensure that beneficiary data undergoes independent review and authorization before those counterparties can be used in payment transactions. This approval mechanism validates counterparty account information, verifies business relationships, and confirms compliance requirements separate from the payment approval process.

Unlike payment approvals that authorize individual transactions, counterparty approvals authorize the beneficiary relationship itself. Once approved, a counterparty becomes available for use in payments. This separation means organizations control both who can be paid (counterparty approval) and which specific payments are authorized (payment approval).

Why separate counterparty approval

Counterparty approval addresses distinct risks from payment approval. While payment approval controls transaction authorization, counterparty approval controls the introduction of new beneficiaries into the system and modifications to existing beneficiary data.

Risk addressed

Data accuracy: Counterparty information—IBAN, BIC, beneficiary name—must be accurate to ensure payments reach the intended recipient. Independent review catches data entry errors before they cause misdirected payments.

Fraud prevention: Unauthorized counterparty creation represents a fraud vector. Requiring approval prevents individuals from adding beneficiaries without oversight, reducing the risk of payments to fraudulent accounts.

Compliance validation: Counterparty approvals provide a checkpoint for compliance checks such as sanctions screening, business relationship documentation, and anti-money laundering requirements before a beneficiary can receive payments.

Relationship control: Organizations may have policies about which entities can be paid. Counterparty approval enforces these policies by requiring authorization before beneficiaries are added to the approved payee list.

The counterparty lifecycle

Counterparties move through distinct stages from creation through approval to active use in payments.

Lifecycle stages

Creation: A user with creation permissions adds a new counterparty by entering beneficiary details—account information, name, address, and supporting documentation. This creates a counterparty in pending status. Counterparties can also be created through bulk import or during payment creation workflows.

Pending approval: The counterparty remains in pending status, unusable for payments. The system identifies eligible approvers—users with authorization permissions who did not create the counterparty. Eligible approvers receive notifications about the pending counterparty.

Review and authorization: An approver reviews the counterparty information, verifies account details and documentation, and either approves or rejects the counterparty. The four-eyes principle prevents self-approval—the creator cannot approve their own counterparty entries.

Active availability: Upon approval, the counterparty becomes active and available for use in payments. Users can select this counterparty when creating credit transfers or other payment types. The counterparty remains active until deactivated through administrative action.

Modification approval

Changes to existing counterparty information also trigger the approval workflow. When a user modifies counterparty details, those changes remain pending until approved by a separate user. The counterparty continues functioning with its previous information while modifications await approval. Upon approval, the updated information replaces the original data.

Approval permissions and access

Counterparty approval uses dedicated permissions separate from payment approval permissions. This allows organizations to assign different individuals to authorize beneficiary relationships versus authorize transactions.

Permission separation

Users may have permission to create counterparties but not approve them, or permission to approve counterparties but not create them. This separation enforces true maker-checker separation where no individual controls both sides of the process.

Organizations can configure which users can create counterparties, which users can approve them, and which users can perform both functions (though the system prevents self-approval regardless of permissions).

Counterparty scoping

Approval workflows respect counterparty data scoping. Users can only approve counterparties they have permission to access based on counterparty group assignments and permission configurations. This maintains data segregation while allowing appropriate approval flows.

Bulk operations and approval

When counterparties are created through bulk import, the approval workflow applies to all imported records. The bulk import creates multiple pending counterparties simultaneously. Approvers review and authorize these counterparties individually or in batches. Rejected counterparties from bulk imports can be corrected and resubmitted through the standard creation workflow.

Relationship to payment approval

Counterparty approval and payment approval represent two independent control points in the payment process. Both must be satisfied for a payment to reach the bank.

Sequential validation

Payment creation first validates that the selected counterparty is approved and active. If the counterparty is pending or rejected, it cannot be selected for payments. Once a payment is created with an approved counterparty, that payment then enters the payment approval workflow controlled by signatory rules.

This sequential validation means adding a new beneficiary requires counterparty approval before any payments can be created to that beneficiary. Once approved, future payments to that counterparty only need payment approval.

Different approval criteria

Counterparty approval evaluates beneficiary relationship validity and data accuracy. Payment approval evaluates transaction characteristics like amount, account, and payment category. Different users may be authorized for each type of approval based on their roles and responsibilities.

Support

For questions about counterparty approval concepts or access control strategy, contact [email protected].