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, during payment creation workflows, or via the FinologeeBKO API.

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. Authorization can be performed through the FinologeeBKO user interface or via the API.

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.

API-driven counterparty approval

External systems can perform counterparty approval through the FinologeeBKO Payments API, enabling organizations to manage the approval step within their own systems without requiring manual action in the FinologeeBKO user interface.

This capability is designed for integration scenarios where counterparty onboarding and validation occur in an external system. Creating the counterparty via API before the external approval step completes allows FinologeeBKO to validate the IBAN and BIC at creation time, confirming account details are accurate before approval is granted.

The four-eyes principle applies to API-driven approval in the same way it applies to UI-driven approval: the API credentials used to approve a counterparty must belong to a different user or service account than the one that created it.

For full details on the API endpoints and request structure, see API - FinologeeBKO Payments API reference.

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].