The role

• 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

• 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

• 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

• 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

• 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 QA

• Drive 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

• 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

• 4+ years in bank/payments implementation, treasury implementation, cash management onboarding, or technical implementation at a fintech, bank, ERP, or treasury management system vendor

• Working fluency with ISO 20022 payment and reporting messages — pain.001, pain.002, camt.052/053 — and with NACHA ACH files. You should be able to open a file, read it, and tell us why the bank rejected it

• Experience reading a bank's ISO 20022 implementation guide and turning it into a specification a development team can build from. This is not a "familiar with ISO" requirement — you will be the person in the room with the bank's format team agreeing field-level detail

• A track record of reducing implementation cycle time, with numbers. Tell us what a project took before you owned it and what it took after

• Practical experience with host-to-host bank connectivity: SFTP, PGP/GPG encryption, SSH key pairs, key rotation

• Demonstrated ownership of bank certification/UAT cycles, including managing a bank's test script tracker to sign-off

• Willingness to negotiate with a bank rather than accept their first answer — on format deviations, on test scope, and on timeline

• Understanding of payment instruction data: account numbers, currency, IBAN, BIC/SWIFT, cross-border requirements

• Genuinely comfortable client-facing — you'll be on calls with controllers, CFOs, and bank relationship teams, and you'll be the one delivering bad news about timelines

• Able to run 3–6 concurrent projects with dependencies you don't control, and keep every stakeholder honest about status

• Overlap with India business hours for daily coordination with dev and QA

• Alternative asset management or fund administration background — you already know why one payment can hit multiple entities

• Direct experience onboarding to specific banks: JPMorgan, Citi, BNY, Goldman, HSBC, Northern Trust, First Republic-style regional banks

• Greenfield experience: having been the first person to connect a platform to a given bank, not only repeating an established integration

• SWIFT MT formats (MT101, MT940/942), RTP, Fedwire

• Bank reconciliation and cash application workflows

• Familiarity with Azure DevOps or similar for tracking work with engineering

• Basic scripting or comfort in a terminal (openssl, gpg, sftp clients)

• You do not need to write production code. You need to specify precisely, test rigorously, and know when a dev's answer doesn't add up.