Advanced Back Office Notifications Guide

For Bank / Partner Administrators

This guide explains every email notification PayRecs sends to your side — your back-office / admin team (the FI Users you add to PayRecs) and the addresses you configure on your partner profile. For each it covers the events that trigger it, who receives it, and how to control the recipient lists. These are distinct from the notifications your customers (the companies and end users you serve) receive.

Recipients fall into two buckets:

• FI Users — individual people on your team, each with their own login and permissions. Who receives an email is decided by that person's permissions / notification preferences.

• Configured addresses — shared mailboxes you set on your partner profile (a case inbox, a treasury inbox, return-notification and compliance-alert addresses). These go to whatever address(es) you've configured, regardless of individual user permissions.

There are eight families of back-office notifications:

1. Onboarding & account setup — new admin users, and customer companies/subsidiaries going live.

2. Approval notifications — when a payment needs your team's review (standard and high-value).

3. Scheduled payment behavior — how approval notifications differ for payments scheduled in advance.

4. Returns & reversals — when a payment can't complete and customer funds must be returned.

5. Incoming funds — when money arrives into an account that's hidden from the customer.

6. Treasury / online banking — when a banking transfer fails or is misconfigured.

7. Compliance holds — when a payment is flagged for fraud or sanctions review.

8. Case notifications & daily digest — when a payment exception needs attention or customer action.

In the subject lines below, text in {braces} is filled in per payment (company name, PayRecs payment ID, etc.).

1. Onboarding & Account Setup

"Ready to launch" emails go to FI Users who hold the manage-companies permission (and are copied to your treasury support address). They are not sent for back-office companies.

2. Approval Notifications

Separate from the daily reminders your customers receive, PayRecs notifies your back-office team by email whenever a payment reaches a point where your side needs to review or approve it before it can move forward. These are real-time, event-driven emails — they fire the moment a payment enters a review state, not on a daily schedule.

There are two types: standard approval and high-value approval.

Standard approval needed

When it's sent: A payment moves into back-office review (it requires partner approval before processing).

Subject line: "Approval Needed for payment from {Company Name} ({Payment ID})"

Who receives it: Members of your back-office team who hold the matching approval permission for that payment. Permissions are granular — they're split by payment type and payer type, so a user only gets the email for the categories they're allowed to approve:

A back-office user with none of these permissions receives nothing; a user with only some receives only the matching categories.

High-value approval needed

When it's sent: A back-office payment exceeds the high-value threshold and enters a separate high-value review state.

Subject line: "High Value Approval Needed for payment from {Company Name} ({Payment ID})"

Who receives it: A narrower group — back-office users specifically permitted to approve high-value payments, again split by payer type (high-value back-office corporate vs. high-value back-office consumer). This is intentionally a tighter list than standard approval so large payments get senior sign-off.

Follow-up emails: Once a high-value payment is acted on, the same group is notified of the outcome — an approved ("Payment from {Company} ({Payment ID}) High Value Approved") or rejected ("… High Value Rejected") confirmation email.

Key things to know as an administrator

• Permissions decide the recipient list — not seniority or a fixed group. To change who gets these emails, adjust the relevant approval permission on each back-office user's profile.

• The split between back-office and end-user payments matters. A payment your team originates and a payment a customer originates route to different permission checks, even if the rest looks identical. Make sure the people who should see each kind actually hold that specific permission.

• High-value is a deliberately separate, tighter path. Standard-approval permission does not automatically include high-value approval. If high-value emails aren't reaching the right people, check the high-value permissions specifically.

• Customer payments that need your approval skip the customer's own approval reminder for that stage and come to your back-office team instead — so this email may be the only signal that a payment is waiting on you.

In short: When a payment needs your bank's review, PayRecs emails the back-office users who hold the matching approval permission — broken out by payment type, payer type, and (for large payments) a separate high-value permission. These are immediate, event-based emails, and the recipient list is controlled entirely by the approval permissions you assign.

3. How Scheduled Payments Work Differently

Scheduled payments follow a fundamentally different timeline from immediate payments, and it's important your back-office team understands it so nobody is waiting on — or surprised by — an approval email.

The core difference: nothing reaches your back office until the scheduled date

When a customer creates a scheduled payment, it is not a real payment yet — it's an instruction to create one later. During this waiting period:

• Your back office receives no notification at all. There is no "a payment is scheduled" email, no advance heads-up, and no daily digest on the partner side.

• All the activity in this window is customer-side: their own approvers handle approving the schedule, and they receive the daily reminders.

Your back office only enters the picture on the scheduled date itself.

What happens on the scheduled date

When the scheduled date arrives, a background process runs (within a configured processing window for each payment segment) and converts the schedule into a real payment. Only at that moment is the payment evaluated against your partner approval rules.

If that newly created payment meets the conditions for back-office review, that's when your team gets the standard or high-value "Approval Needed" email — exactly the same emails described in section 2. Until then, there is nothing to act on.

In short: For an immediate payment, your approval email arrives within seconds of the customer submitting it. For a scheduled payment, your approval email arrives on the scheduled date, once the payment is actually created — never before.

Why timing matters: "Approval rules applied"

The single most important thing to understand about scheduled payments is when your approval rules are checked — because it is not when the customer schedules the payment.

Immediate payments — rules checked at submission. When a customer submits an immediate payment, PayRecs evaluates your back-office approval rules right then, against:

• your approval thresholds as configured at that moment,

• the payment's value converted to your home currency using that moment's FX rate, and

• any first-payment or high-value rules in force at submission.

What you see is what was true the instant the customer hit submit.

Scheduled payments — rules checked at execution, not at scheduling. When a customer creates a scheduled payment, no approval evaluation happens for your side yet. The schedule simply waits. Your approval rules are only applied on the scheduled date, when the schedule is turned into a real payment, and that evaluation uses whatever is true on execution day:

• Your thresholds at that time. If you raise or lower an approval threshold between the scheduling date and the execution date, the new threshold applies. A payment scheduled weeks ago is judged by today's rules.

• The FX-converted amount at that time. The payment's value in your home currency is recalculated using the execution-day rate. Because rates move, the converted amount compared against your threshold can be higher or lower than it would have been on the scheduling date — which can push a payment over (or under) an approval or high-value threshold.

• First-payment / high-value logic as it stands that day.

Why this matters in practice:

• A scheduled payment can require your approval on its execution date even though it wouldn't have when it was scheduled — for example, because FX movement pushed its value over your high-value threshold, or because you tightened a threshold in the meantime.

• The reverse is also true: a payment that would have tripped a threshold weeks ago may pass without review if your thresholds were raised before it executed.

• Threshold changes are not retroactive to a "locked in" snapshot, and they are not ignored either. They take effect for any scheduled payment that executes after the change. There is no snapshot of the rules taken at scheduling time.

Rule of thumb: Think of a scheduled payment as being "priced and checked" on its execution date, not on the date it was created. If you change approval thresholds, assume the change will affect every scheduled payment that hasn't executed yet.

The tight action window

Because the back-office email only fires on the scheduled date, your team's window to act is shorter and more time-sensitive than with immediate payments. Treat a back-office approval email for a payment that's due that same day as urgent.

When you'll never see a scheduled payment at all

A scheduled payment that required the customer's approval but was not approved by their side by end of day on the scheduled date is automatically cancelled — the real payment is never created. In that case your back office is never notified, because from your side the payment never existed.

Note also: even if the customer did not require their own approval on the schedule, your partner thresholds are still applied when the payment is created. So a scheduled payment can still land in your back-office approval queue on its scheduled date based on your rules alone.

Quick comparison

4. Returns & Reversals

When a payment can't complete and the customer's funds need to be returned or reversed, PayRecs emails the return-notification address(es) configured on your partner profile (not individual users).

If the return-notification address isn't configured, these emails silently don't go out (and PayRecs is alerted internally). If your team isn't receiving them, confirm the return address on your partner profile.

5. Incoming Funds

The customer is deliberately not notified while the account is hidden — they'll receive the standard "incoming wire received" notification once you make the account visible. This email exists to prompt your team to act on funds the customer can't yet see.

6. Treasury / Online Banking

7. Compliance Holds

PayRecs screens payments through compliance systems (such as fraud monitoring and sanctions screening). When a payment is flagged, PayRecs places it on hold and emails your compliance contacts so it can be reviewed.

When it's sent

A compliance hold email is sent when a screening result requires manual review — specifically:

• a fraud scan returns a hold, or

• a sanctions scan returns a match.

Subject line: "Hold for Invoice {Invoice / Reference} ({Payment ID})"

Who receives it

Recipients are taken from your partner compliance configuration, and the list depends on the type of flag:

• Fraud holds go to the email address(es) configured for fraud monitoring.

• Sanctions matches go to the email address(es) configured for sanctions monitoring.

These are configured separately, so you can route fraud and sanctions alerts to different teams if you wish. Each can hold one or more addresses.

Important: Compliance hold recipients are not controlled by the per-user approval permissions used for approval emails. They are driven entirely by the fraud-monitoring and sanctions-monitoring email addresses in your partner configuration. If the right people aren't being alerted, update those configured addresses.

What happens to the payment

When a compliance hold fires, the payment is placed in a hold status and cannot proceed until it is reviewed. The review itself happens in your compliance vendor's dashboard (e.g. Verafin or LexisNexis), not inside PayRecs. The hold email directs your team there to investigate and clear or reject the payment.

No "cleared" / "released" email

There is no automatic email when a hold is resolved. When a payment is released (or rejected) in the vendor dashboard, PayRecs records the status change, but it does not send a follow-up "hold cleared" notification. Your team should track resolution in the compliance dashboard rather than expecting a closing email.

In short: A fraud hold or sanctions match puts the payment on hold and emails the compliance address(es) configured for that flag type. Reviewing and clearing the hold is done in your compliance vendor's dashboard — and there's no separate email when it's resolved.

8. Case Notifications & Daily Digest

What is a "case"?

A case is a payment exception — an issue raised when a payment needs additional information or action before it can complete. Cases are commonly opened to request something from the sender on behalf of a processor, a beneficiary bank, or a downstream bank, or to resolve an operational/compliance issue.

A case can be tied to a payment that is on hold (it can't proceed until the case is resolved) or to one that is still moving but at risk of a delivery problem. Cases progress through statuses such as waiting on customer → in review → resolved (or cancelled), and a single payment can have more than one case (numbered like PYR-12345-1).

There are four case-related emails to your back office.

A. Case created

When it's sent: When a case is opened with an internal note. (Opening a case without an internal note does not trigger this partner email.)

Subject line: "Payment {Payment ID} [on Hold] - Customer Action Required" (the "on Hold" portion appears only when the payment is held).

Who receives it: A combined list of —

• the address(es) in your partner case email configuration (one or more, comma-separated), plus

• back-office users who have the "notify on case created" preference enabled on their profile.

B. Case updated

When a case is updated, PayRecs sends one of two emails depending on who made the update:

• Update made by your/admin side → goes to the partner.

  • Subject: "Payment {Payment ID} Case has been updated"

  • Recipients: the address(es) in your partner case email configuration only.

  • Note: Unlike the "case created" email, this update email does not also go to the per-user "notify on case created" list — it relies solely on the configured case email address(es). If you want individuals to receive update emails, make sure they're included in the case email configuration.

• Update made by the customer (end user) → goes to internal PayRecs PayOps.

  • Subject: "Case {Case Number} | {Payment ID} has been updated"

  • Recipients: internal PayRecs operations staff who can view cases. (This path notifies PayRecs, not your back office.)

The rule of thumb: updates flowing out from your side notify your configured case email; updates coming in from the customer notify PayRecs PayOps.

C. Case resolved

When it's sent: When a case is resolved.

Subject line: "Payment {Payment ID} Case Resolved"

Who receives it: Back-office users who are case commenters with the "notify on case resolution" preference enabled, and who have view access to that payment's type (back-office/end-user × corporate/consumer).

D. Case daily digest

When it's sent: Once nightly, as part of the scheduled overnight job, only if cases are enabled for your partner.

Subject line: "Daily Digest - Unresolved Cases"

Who receives it: A combined list of —

• the address(es) in your partner case email configuration, plus

• back-office users who have the "receive daily digest" preference enabled on their profile.

What it contains: A summary of outstanding cases — both unresolved cases overall and, called out separately, cases that have been waiting on the customer beyond your case SLA (a configurable number of days). Each entry shows details such as the company, case number, who initiated it (name / phone / email), and how long it has been active, so your team can prioritize follow-ups.

Controlling case recipients

There are independent per-user preferences plus the shared case-email configuration:

In short: Your partner case email configuration is the backbone for created/updated/digest emails. Separate per-user preferences let individual back-office users opt in to new-case alerts, resolution alerts, and/or the daily digest. Case update emails to your side rely on the configured case email only.

Quick Reference: Who Gets What

Notes on timing and control

• Onboarding/launch, approval, high-value, case-resolution, and hidden-MCA emails are routed by per-user permissions/preferences — change them on each FI User's profile.

• Approval and high-value emails are immediate and event-driven.

• Scheduled payments generate their back-office approval email on the scheduled date, not when scheduled — and are evaluated against your rules as of that day.

• Returns/reversals, treasury, compliance, case-created/updated, and the daily digest are routed (wholly or in part) by addresses configured on your partner profile — update those addresses to change the recipients.

• Compliance holds are reviewed in the vendor dashboard, with no "cleared" email.