Protecting Your Payments from Fraud and Scams
Last updated: May 15, 2026
Audience: Corporate users who create, approve, or manage international payments and recipients in PayRecs.
Cross-border payments are a favorite target for fraud because the dollar amounts are large, the destinations are unfamiliar, and recovery is difficult once funds leave the country. This guide explains where fraud actually happens, the controls your bank and PayRecs already have in place to protect you, and the habits that close the remaining gaps.
Where Fraud Actually Happens
Most people assume fraud happens at the moment a payment is sent. In practice, the highest-risk moment is when a recipient is created or edited.
A payment sent to a recipient with the wrong banking information goes to the wrong place, even if every approval step is followed correctly. Attackers know this. The dominant attack pattern is Business Email Compromise (BEC), where a bad actor impersonates a vendor, executive, or customer and sends what looks like a legitimate request to update banking details or pay an invoice to a new account.
By the time the payment is created, the damage is already done. The payment looks normal. The amount matches the invoice. The approver sees nothing unusual. The money goes to the attacker's account.
This is why the most important fraud control is not at payment time. It is at recipient creation.
Controls Already in Place
Your bank has configured a layered set of controls inside PayRecs. Not every bank turns on every control, so the exact mix may vary, but the building blocks are the same.
Multi-factor authentication (MFA)
MFA can be required at three separate moments:
Creating a payment
Approving a payment
Creating a recipient
These are independently configurable. The most secure posture, and the one we recommend banks enable, is MFA on all three. MFA at recipient creation in particular blunts the BEC attack vector described above, because an attacker who has phished a user's password still cannot add a fraudulent recipient without the second factor.
When mass-approving payments, a single MFA code typically covers the batch, and a configurable session window can allow consecutive approvals without re-prompting for a code each time.
Dual approval (dual control)
Dual approval means a second person must approve before an action takes effect. PayRecs supports dual control independently for:
Payments: the creator cannot also be the sole approver. A second user must approve before funds move.
Recipients: the user who creates or edits a recipient cannot activate it alone. A second user must approve before the recipient can receive payments.
Self-approval is a separate permission. Even users with self-approval still complete a two-step process (create, then approve). Single-step submission is not supported.
Dual approval on recipients is the single most effective control against BEC. Even if an attacker compromises one user's credentials and convinces them to add a fraudulent recipient, the change does not go live until a second user reviews and approves it.
Limits
Payment limits are configured by your bank and enforced at submission. A payment that exceeds the user's limit, the company limit, or the per-transaction limit cannot be created. Limits are also one of the easiest controls to right-size as your business changes; ask your bank's back office to review them periodically.
Good-balance and entitlement checks
PayRecs verifies the funding account has sufficient balance before a payment is created, and it verifies the user's entitlements at every step. If your role does not permit creating, approving, or sending payments above a certain amount, the system will not let you do it. This is one of the reasons keeping entitlements accurate matters (see below).
Real-time sanctions and fraud screening
Depending on your bank's configuration, payments and recipients are screened in real time against sanctions lists (OFAC and equivalents), watchlists, and fraud signals. Some banks integrate directly with vendors such as Verafin or LexisNexis. When a hit occurs, the payment is held in a Compliance Review state until your bank's compliance team clears it or contacts you for more information. You may receive a case in the Cases tab asking for additional documentation.
Duplicate detection
PayRecs warns you when a similar payment to the same recipient has already been sent within a recent lookback window. This is not foolproof, but it catches the most common type of accidental or fraudulent double-pay.
What You Should Do
The controls above only work if your habits support them.
Verify recipient banking information out of band
Any time someone asks you to add a new recipient or change an existing recipient's banking details, verify the request through a separate channel before you make the change in PayRecs. Call a known phone number for the vendor. Do not use the contact information in the email itself, because if the email is fraudulent the phone number will be too. Confirm verbally with a person you know.
This single habit prevents the majority of cross-border fraud.
Treat change-of-account requests as suspicious by default
A legitimate vendor changing their bank account is a real event, but it is also the exact scenario attackers exploit. Common red flags:
The request comes by email only.
It carries urgency ("we need this updated before the next payment runs").
It comes from a slightly altered email address (extra letter, swapped domain).
The new account is in a country or at a bank the vendor has not used before.
The vendor goes silent or unreachable when you try to verify by phone.
Any one of these warrants out-of-band verification. Two or more should stop the change.
Use the approval workflow as designed
Do not work around approvals. If your company has dual control on payments or recipients, the second approver is a control, not a bottleneck. Bypassing it (for example, by asking the approver to approve without reviewing) removes the control entirely.
If the approval process is slowing legitimate work down, talk to your bank about adjusting thresholds, adding approvers, or reviewing your entitlements. Do not work around the controls themselves.
Keep entitlements current
Review who in your company has access to PayRecs and what they can do. When someone changes roles or leaves, notify your bank's back office promptly so their entitlements can be updated or removed. A user who left six months ago with payment-creation rights is a standing risk.
Take compliance holds seriously
If a payment lands in Compliance Review or a case is opened on a payment, respond promptly with the information requested. Compliance holds are not a hassle. They are the system doing its job.
Report anything that feels off
If you receive a notification about a payment or recipient you did not create or approve, contact your bank immediately. The PayRecs notification email comes from your bank's name as the sender and shows in your inbox under the bank's branding; the underlying domain is payrecsapp.com. Confirm any suspicious notification with your bank.
Quick Reference
If this happens... | Do this |
|---|---|
A vendor emails you new banking info | Call the vendor at a known number before updating the recipient |
Someone asks you to "approve quickly" outside normal process | Stop. Verify through a separate channel |
You see a payment or recipient you did not create | Contact your bank immediately |
You get a compliance case on a payment | Respond promptly through the Cases tab |
An employee leaves the company | Notify your bank's back office to remove their access |
You hit an MFA prompt you did not expect | Cancel and contact your bank. Do not enter the code |
If you have questions about how your bank has configured these controls for your company, or you want to adjust thresholds, approvers, or entitlements, contact your bank's back office team. Your bank can also walk through any specific scenario with you.