Security and Fraud Controls in PayRecs: Bank User Guide

Audience: Partner-bank back office, operations, BSA/AML, fraud, and compliance staff responsible for fraud prevention and response on PayRecs.

Scope: Every fraud-relevant control available in PayRecs, what each one does, when to use it, and what it protects against. For how these controls fit into the full approval pipeline, see the companion Back-Office Payment Approvals: Bank User Guide (https://www.notion.so/3600686525528171b89ef4d1f6a27c36).

Where fraud actually happens

The highest-risk moment in the cross-border payment lifecycle is recipient creation, not payment creation. Once a recipient is in the system with valid-looking banking details, payments to that recipient look entirely normal to your end users, your approvers, and to most automated controls.

The dominant attack vector is Business Email Compromise. An attacker impersonates a vendor or executive and convinces an end user to add or edit a recipient. By the time the payment is created, the damage is already done. The amount looks right, the approver sees nothing unusual, and the money moves.

This shapes how to prioritize. Controls that act at recipient creation (B, C, D below) deliver more protection per dollar of operational cost than the same control applied at payment time. The controls are listed roughly in lifecycle order: recipient first, then payment creation, then payment approval.

Control catalog

A. Limits and balance checks

What it is. Dollar limits set per user, per company, and per transaction, plus a balance check on the funding account. Enforced when the payment is submitted, before any approval queue.

Important. First-line control. A payment that would exceed any limit, or that lacks available balance, never enters the pipeline. Right-sized limits are far more effective than blanket high limits paired with downstream approval; a tight limit caps the size of the loss event itself.

Example. Customer historically sends payments under $50k. Limit set to $75k. An attacker who compromises a user's credentials cannot send a $500k payment regardless of any other control.

Gotcha. Limits set at onboarding drift. Review annually at minimum, and any time the customer's profile changes materially.

B. Recipient dual control

What it is. A second user must approve a newly created or edited recipient before payments to that recipient are allowed. The user who created the recipient cannot approve it.

Important. The single most effective control against BEC. An attacker who compromises one user's credentials and convinces them to add a fraudulent recipient still cannot get the recipient activated. A second pair of eyes is required.

Example. User A adds a new vendor with banking in a country the customer has not paid before. The recipient sits pending until User B reviews. User B catches the unusual country, calls the vendor at a known number, discovers the request was fraudulent, and rejects the recipient. Loss prevented at $0.

Gotcha. Recipient dual control and payment dual control are completely independent. A customer with payment dual control on, recipient dual control off, has the most common attack vector unprotected.

C. MFA on recipient creation

What it is. An MFA challenge required when a recipient is created or edited. Separate from MFA on payment actions.

Important. Strongest when combined with recipient dual control (B). The creator authenticates with the second factor at submission, and the independent approver still reviews before the recipient goes live. A phished password alone is not enough.

D. First-payment review

What it is. Forces the first payment to any new vendor recipient into back-office partner approval, regardless of amount. Available in both back-office and end-user paths.

Important. Gives the back office a chance to scrutinize every new payee on its inaugural payment, which is exactly when BEC typically executes. The next payment to the same recipient (after this one is approved) does not retrigger.

Example. Customer enables first-payment review on the back office side. A $500 corporate payment to a brand-new vendor lands in partner approval despite being well below the amount threshold. Back office calls the customer to verify, discovers the user did not actually request this vendor, and the fraud is caught at $500 instead of $50,000 a month later.

Edge case. First-payment review only fires on tracked vendor recipients. For non-vendor destinations, the rule is treated as already satisfied.

E. MFA on payment creation

What it is. MFA challenge required when a payment is submitted.

Important. Less impactful than MFA on recipient creation (C). By the time fraud reaches the payment-creation step, the recipient is the real vulnerability. Still valuable when user credentials may be compromised.

F. Duplicate detection

What it is. Warns when a similar payment to the same recipient has been sent within a recent lookback window.

Important. Catches accidental and naive-fraud double-pays. Sophisticated fraud usually varies amount and timing to avoid this signal.

G. Payment dual control

What it is. Standard two-person rule on payment approval. The creator cannot be the sole approver.

Important. Self-approval is a distinct permission. Users with self-approval still complete a two-step process (create, then approve). This is not single-step submission. Companies configured with full entitlement and no dual control do process payments without a separate approval step; review whether any of your customers should be in that posture.

Example. User A creates a $25,000 payment. User A holds the approval permission but does not have self-approval. The payment sits in pending approval until a different user reviews and approves.

Gotcha. Dual control on payments without dual control on recipients gives false comfort. A fraudulent recipient produces fully approved fraudulent payments.

H. MFA on payment approval

What it is. MFA challenge at the moment a payment is approved. Session duration is configurable.

Important. Mass approval uses a single MFA code for the batch. This is by design, not a bypass. The approver still authenticates with the second factor.

Configuration tradeoff. Short MFA sessions strengthen security but increase user friction. Banks typically align this with the core platform's existing MFA session policy for consistency.

I. Standard partner approval threshold

What it is. A dollar threshold that routes payments above it into back-office partner approval. Set separately for back-office payments and end-user payments.

Important. End-user thresholds can be overridden at the individual company level. The company-level override is absolute: if set, the partner-level default does not apply for that company.

Gotcha. A company-level override of $0 sends every end-user payment from that company to partner approval. Useful posture for high-risk customers. A company-level override higher than the partner default makes that company looser than the default; there is no clamp.

Example. Partner default for corporate end users is $10,000. A high-risk customer has their company-level override set to $0. Every payment that customer's end users create routes to back office for partner approval, regardless of amount.

Surfacing. End-user partner approval appears in your queue only after in-company user approval is complete. If a customer reports a payment is "missing" from your queue, confirm whether their internal approval has cleared.

J. High-value partner approval threshold

What it is. A second approval gate above a higher dollar threshold. Back-office payments only.

Important. Fires after standard partner approval. A high-value payment is approved twice: once at standard partner approval, then again at high-value approval. Use a separate approver pool from standard approval to preserve independence.

Example. Standard threshold is $25,000. High-value threshold is $250,000. A $500,000 back-office payment lands in standard partner approval first; once approved, it moves to high-value approval with separately permissioned approvers.

K. Blind key verification

What it is. An independent back-office operator must re-key the recipient's account number or IBAN before payment can be approved.

Important. Back-office payments only. End-user payments never hit this gate. When enabled, the payment automatically requires partner approval even if it is below the amount threshold; blind key cannot stand alone.

Example. Customer requests a high-trust posture on every back-office payment. Partner enables blind key on corporate back-office payments. Every corporate back-office payment, regardless of amount, must pass blind-key verification and partner approval before moving forward.

L. Compliance and sanctions screening

What it is. Sanctions, watchlist, and fraud screening through a compliance vendor (Verafin, LexisNexis, or partner-specific equivalents). Hits land in compliance review.

Outcomes.

• Auto-clear: vendor returns no hit, payment moves on to the next gate.

• Case opened: vendor flags a potential match. The payment enters a pending-case state. Status shows as Pending Case (waiting on bank) or Needs Attention (waiting on customer). On resolution it either continues or cancels.

Important. Cases notify the end user by email and surface in the Cases tab. Customers can respond directly in the app, or back office can respond on their behalf.

Edge case. When the trade currency is on the exotic list and a compliance vendor is configured, both compliance review and user approval are forced with no opt-out path. Uncommon, but worth recognizing when you see compliance review on an exotic-currency payment.

Entitlements: the operational layer

Configuration is necessary but not sufficient. Stale entitlements undo the strongest control catalog. Run the review below quarterly.

What does not protect you

Order in which controls fire

A payment moves through gates in sequence, stopping only at the gates that apply. Rejection at any gate cancels the payment. Order varies between corporate and consumer payments and between back-office and end-user paths. See the companion doc for the full state-machine diagrams. Summary:

Corporate back-office: Limits and balance > Compliance > Partner approval > High-value approval > Blind key verification > Payout.

Consumer back-office: Limits and balance > Blind key verification > Partner approval > Funding > Consumer hold > High-value approval > Compliance > Payout.

End-user (corporate or consumer): Limits and balance > In-company user approval > Compliance > Partner approval > Payout. Consumer adds a consumer hold before payout.

Quick reference: "what should I turn on for this risk?"

Quick reference: "why didn't this control fire?"

Configuring controls

Most of the controls in this document are configured by PayRecs at the partner or company level. Contact your PayRecs implementation or support contact to:

• Enable recipient dual control or MFA on recipient creation

• Adjust approval thresholds (back office or end user, standard or high-value)

• Enable first-payment review (back office or end user, partner-level or company-level)

• Enable blind key verification

• Adjust MFA session duration

• Add or modify compliance vendor screening rules

• Set or change a company-level partner approval threshold override

• Adjust limits at user, company, or partner level

Use the normal support channel, or escalate via the partner portal Cases tab for active fraud events in flight.