swel

GlossaryMaker-checker in fund administration

Maker-checker in fund administration

Maker-checker is a dual-control process in which a financial instruction created or entered by one individual (the maker) must be independently reviewed and approved by a second individual (the checker) before it is executed. In fund administration, maker-checker is the standard operational control for payment authorisation: no capital call or distribution payment should be submitted to the bank without a second authorised person having verified the instruction.

The control is effective precisely because it removes the possibility of a single individual, acting alone, initiating and executing a payment, whether through error or fraud.

How it works

In a maker-checker workflow, the maker creates the payment instruction: entering the payee, amount, reference, value date, and routing details. The instruction is then placed in a review queue and cannot be released until the checker reviews the same instruction and affirmatively approves it. The checker's role is not to replicate the maker's work, but to independently verify that the instruction is correct and authorised before it proceeds to the bank.

Effective maker-checker in fund administration requires several conditions to be met:

First, the maker and checker must be genuinely independent. A maker-checker process in which a single person holds both the maker and checker credentials, or in which one person's approval is routinely deferred to without review, provides no meaningful control. For this reason, most fund administration operations policies require that the maker and checker be different named individuals, with system-enforced segregation preventing a user from approving their own instruction.

Second, the checker must have sufficient information to verify the instruction. This means the checker should have access to the underlying source document (the approved capital call schedule or distribution calculation) and should be able to confirm that the payee account details match those in the verified counterparty registry, not merely that the fields are populated.

Third, the checker must have the authority to reject or escalate. A checker who in practice cannot refuse an instruction from a senior colleague, or who receives so many instructions that individual review is not possible in the time available, is not exercising effective control.

In fund administration, maker-checker is typically implemented within treasury management systems, payment portals, and fund accounting platforms that enforce dual-approval workflows at the system level. Many platforms allow administrators to configure approval rules by payment type, amount threshold, or counterparty, so that smaller routine payments (such as management fee disbursements to a standing payee) may require only one approver, while irregular large-value payments require two or more.

Maker-checker does not eliminate fraud. A collusive arrangement between the maker and checker, or a situation where the checker is pressured or deceived by the maker, can circumvent the control. For this reason, maker-checker works most effectively when combined with system-level controls that make data manipulation detectable (such as audit logs that record every change to a payment instruction) and with periodic independent review of payment activity.

Worked example

Castlegate Fund Services processes a distribution payment of GBP 6.4 million to seventeen LPs in a mid-market buyout fund.

The payments analyst (maker) loads the distribution schedule, matches each LP against the firm's verified payee registry, and creates seventeen individual payment instructions in the payment system. The system flags the batch for approval and sends an automated notification to the senior payments manager (checker).

The checker reviews each instruction against the approved distribution schedule and the verified registry. On instruction twelve, she notices that the amount differs from the schedule by GBP 12,000. She rejects the batch, adds a comment identifying the discrepancy, and returns it to the maker for correction.

The maker identifies a transposition error in the LP's distribution amount (GBP 641,000 entered as GBP 629,000) and corrects it. The corrected batch is resubmitted and approved by the checker. The payment is released.

Without maker-checker, the error would have been submitted to the bank and would have required a recall request and reconciliation process. With maker-checker, it is caught pre-execution at zero cost.

Frequently asked questions

What is the minimum number of approvers required for a maker-checker control to be effective? Two is the standard minimum: one maker, one checker. Some fund administrators implement a three-level hierarchy for payments above a defined threshold, requiring a senior approver or director sign-off in addition to the standard checker. The appropriate number depends on the payment amount, the risk profile of the counterparty, and the administrator's internal control framework. Regulatory guidance (including CSSF and Central Bank of Ireland guidance on outsourcing and operational risk) generally requires dual authorisation for material financial transactions.

Can maker-checker be automated? The payment execution chain can include automated steps, but the approval step itself must involve a human with genuine authority to review and reject. An automated system that routes payments through a nominal approval queue with no human review is not a maker-checker control. That said, maker-checker can be embedded within a straight-through processing workflow: the maker and checker complete their roles, and all downstream processing from approval to settlement is automated.

What happens if the checker is unavailable and a payment is time-sensitive? Fund administration operations should have documented escalation procedures for situations where the primary checker is unavailable. Options include a designated alternate approver with equivalent authority, an escalation to a more senior individual, or a defined delay protocol. Ad hoc override of maker-checker requirements due to time pressure is a significant control failure and should be a red flag for internal audit.

Does maker-checker prevent fraud if the maker and checker collude? No. Collusion between maker and checker is the principal limitation of the control. This is why maker-checker should be combined with independent audit, transaction monitoring, and periodic reconciliation to a verified record. Segregating payment creation from counterparty registry management (so that neither the maker nor the checker can alter the verified account details they are comparing against) adds a further layer of protection.

Are there regulatory requirements for maker-checker in European fund administration? Dual authorisation for financial transactions is addressed in multiple frameworks applicable to fund administrators, including AIFMD operational requirements, CSSF circular guidance for regulated entities in Luxembourg, and Central Bank of Ireland guidance for QIAIF and ICAV service providers. The specific requirement is typically framed in terms of adequate segregation of duties and internal control frameworks, rather than as an explicit "maker-checker" mandate.

Related terms

Straight-through processing (STP) in fund payments, Golden copy / ABOR, Confirmation of Payee, APP fraud (authorised push payment fraud), Business email compromise (BEC) in capital calls

Related pages

Internal controls for fund payment operations, Swelv for fund administrators