OB Approval Widget

Payments and recipients can be approved directly in online banking without navigating to PayRecs

EPIC Nice Actimize Xceed

User limit remaining balance and User remaining count visuals

Add a visual within the payment wizard or the UI that shows the amount remaining in a companies daily limit and or the companies remaining Count limit for that day. Also we could include visuals for back office within the company profile showing the same. This can reduce end user errors when limits are hit and also allow for back office to troubleshoot end user reach out.

Partner User - Company Search - Slow Performance and Blanking Screen

For partner users, the company search on the home page is very slow in production and the screen goes blank between each letter

FI Revenue Report updates

FI Revenue - a same day rejected DIFF - shouldn't it show here, since FI Revenue was generated? The FI revenue shows on the RETURNED report https://share.zight.com/Z4u8gXO5 EOD Settlement report - Column T - show a sum total at the bottom EOD Settlement report - add fiFxRevenue and fiMarkupBp to the end of the report. Sum fiFXRevenue Bonus EOD Settlement allow for customization of the report columns - basically anything that is available in the predefined report, allow us to enter an array/list of column names in the partner.config report specification that will use those columns and the order of the columns to change out the report file is outputted ensure that SUM columns still sum (technically they are not required to show though)

XAA Report billing account for MCA

for mca originated payments -> use billing account if billing account is undefined, use existing MCAxxxx designation for dda originated payments -> use dda

Add `deliveryMethod` template variable + generic inline mapping syntax to prefund description config

Context Partners can configure the prefund funds-transfer description string with templates like: PR {{paymentId}} {{buyAmount}} {{buyCurrency}} {{recipientLegalName}}[20] {{bankCountryCode}} See docs/prefund-description-config.md for the full reference. Recipient templates expose 8 variables today; there's no way to include the recipient's delivery method (SWIFT vs in-country EFT) in the description. Two related asks bundled here because they're best designed together: New deliveryMethod variable. Generic inline-mapping modifier on the template engine, so a single variable can render different strings per partner without backend code changes. Part 1 — deliveryMethod variable Add a new template variable on recipient prefund templates. Source field: recipient.liveData.DeliveryMethodId Raw values today (from TableConstants.js): W and E Default rendered output: W → Wire, E → Local Files to change (variable-map population in each rail adapter, recipient template only): graphql/src/paymentEngine/rails/InternationalUSDConsWire/InternationalUSDConsWireAdapter.js (~1483–1496) graphql/src/paymentEngine/rails/InternationalUSDCorpWire/InternationalUSDCorpWireAdapter.js (~1580–1593) graphql/src/paymentEngine/rails/InternationalFXConsWire/InternationalFXConsWireAdapter.js (~1536–1549) graphql/src/paymentEngine/rails/InternationalFXCorpWire/InternationalFXCorpWireAdapter.js (~1791–1804) Part 2 — Generic inline mapping modifier Extend FormatUtils.populateDynamicString() (graphql/src/utils/FormatUtils.js, ~L429-454) with an inline mapping modifier that lets a template override the rendered string per raw value. This is generic — works on any variable, not just deliveryMethod. Proposed syntax (engineering can finalize delimiter): {{deliveryMethod}} → "Wire" or "Local" (default mapping in the adapter) {{deliveryMethod|W=Swift|E=Local}} → "Swift" or "Local" (template-level override) {{deliveryMethod|W=SWIFT|E=ACH}}[6] → composes with existing [N] width modifier {{buyCurrency|USD=Dollars|EUR=Euros}} → works on any variable Semantics: If the modifier is present and the raw value matches a key, render the mapped value. If the raw value doesn't match any key in the modifier, fall back to the default rendered value (i.e. what {{var}} alone would render). This keeps the modifier additive — partners only spell out the cases they care about. The [N] width modifier applies after mapping: slice the rendered string, not the raw value. Delimiter (| proposed) must not conflict with any existing template content. If it does, pick another (;, ::, etc.) — flag in the PR. Caveats Recipient templates only. Vostro payments have no recipient and no delivery method. Don't add deliveryMethod to the vostro variable map (substitution throws on undefined variables — see existing caveat #2 in the doc). All 4 flavors (USD/FX × Consumer/Corporate) on the recipient path. Backwards compatible. Templates without the new modifier render unchanged. The modifier is a pure parser extension. Unknown variable still throws. The mapping modifier doesn't suppress th

scrub description

when passing description to the platform for funds transfer, scrub out ampersand might be other characters to add to the list.

Recipient sort and search consistency

recipient list back office: sort: recipient name, company name, search: is kind of case sensitive, this is not very consistent - should be non-case-sensitive, probably a mix of how we search for draft and non-draft: https://share.zight.com/qGuW5DYx end user: sort: name (by nickname), status, search: similar issue here with case-sensitivity https://share.zight.com/ApubzOm8

po box override

For various reasons, banks can't change the PO box address that is present in online banking In order to allow submission to processor, we need a way for the partner user admin to interdict the address. Scope if po box is identified and blocking occurs in the UI (next is grayed out) add a new model that pops up that says Please enter a physical street address. PO Boxes are not accepted for KYC verification and payment remittance." The new modal can capture the new address in a standard form on save, submit the manually entered address to processor, can keep the po box stored on the platformmemtata data ensure that we're not updating the address anywhere going forward (should just be from OB to platform metadata

support widget spacing

Adjust the column and spacing for the support widget to support very long emails

Recipient search issues

When searching recipient list from the Backoffice (under company or the global recipient list), there appears to be issues when searching against draft recipients. Ensure that at least the draft nickname and legal name and account number are included as part of the search Current fields searchable for recipients: | Search Context | User Role | Fields Searched | | -- | -- | -- | | Recipient list page (partner view) | Back Office | nickname, company.name | | Back office recipient list (primary company) | Back Office | nickname | | Back office recipient list (secondary company) | Back Office | nickname | | Pay wizard "Who" search | End User | nickname, Currency, BeneficiaryName, |

on recipient import provide warning if already imported ,show count of imported from q2

MCA start and end bals incorrectly including cancelled payments

Start and end bal queries should exclude cancelled payments. Cancelled payments should still be visible in the statement list but there amounts should affect running balances.