Payments Implementation Manager

Scoping and kickoff

Send and walk clients through the banking scoping questionnaire; collect banking contacts
Run the joint scoping call with the client's bank; translate client requirements into terms the bank's implementation team can act on
Track fee negotiation and SOW execution between client and bank (you don't own the commercials, you own the timeline)
Hold the bank accountable to assigning an implementation manager and keeping the project moving

New bank enablement and ISO specification

When a client brings us a bank StavPay hasn't connected to before, you own defining what we build:
Obtain and interrogate the bank's ISO 20022 implementation guide / message implementation guideline (MIG) and file specifications
Run the technical specification sessions with the bank's format and payments engineering teams: agree the exact pain.001 structure, mandatory and optional fields, character sets, batch vs. single, payment method coverage (ACH, RTP, wire, cross-border), and the reporting messages they will return (pain.002, camt.052/053/054)
Reconcile the bank's requirements against StavPay's existing template model — identify what maps cleanly, what needs configuration, and what genuinely requires development
Write the specification our developers build to, and own it through pre-CAT. Where the bank's requirement is unreasonable or non-standard, push back and negotiate to standard ISO before it becomes custom code we maintain forever
Feed each new bank's specification into a reusable library so the second client onto that bank onboards dramatically faster than the first

Compressing the onboarding timeline

Onboarding duration is currently gated largely by bank-side steps we don't control. Shortening it is an explicit objective of this role, not a nice-to-have:
Instrument the process: measure cycle time per phase, per bank, and know precisely where time is lost
Build the case with each bank and negotiate faster paths — earlier IM assignment, parallel rather than sequential workstreams, pre-agreed test scenario sets, reduced certification scope for banks we've already been certified on
Run steps in parallel wherever the dependency allows (spec analysis alongside key generation, client data collection during bank testing) rather than accepting the bank's default serial sequence
Escalate stalls through the right channel — the client's banking relationship manager, not just the implementation manager
Front-load everything client-side (entity details, debit accounts, banking contacts) so we are never the reason a bank milestone slips
Turn each onboarding's lessons into a shorter runbook for the next one

Technical setup and key exchange

Request and coordinate SSH/PGP key generation (2048-bit RSA) for UAT and production via our internal CMS; route for internal approval
Exchange public keys with the bank over encrypted channels
Verify initial SFTP connectivity for both UAT and production; store keys correctly in the key vault
Work with the dev team on payment template configuration and FTP/PGP-to-template mapping — you specify and verify, they build

Testing and bank certification

Collect legal entity and debit account details (account number, currency, IBAN/SWIFT for cross-border) from the client
Coordinate creation of test vendors and payment instructions with QADrive the bank's testing tracker to completion — every required scenario passing — and secure formal bank approval
Push the bank to file the move-to-production request
Production cutover and handoff
Connect to production SFTP; coordinate template mapping to the production connection
Enable and validate CAMT reporting jobs; confirm receipt of pain.002, camt.052/053 and ACH return files
Run the live penny test with the client and confirm it auto-reconciles end-to-end
Close the project out cleanly — remove internal users from workflows, clear test data
Hand off to Support and the onboarding BA with documentation good enough that they never need to call you