We need a senior, payments-literate Business Analyst who can take raw business ideas for our client's payments platform and turn them into analyzed, sized, development-ready work — so the bank's senior engineers can go back to engineering.

Role snapshot

Title: Senior Business Analyst, Payments / API Platform
Product: an API-driven B2 B payments platform with a few UIs.
Engagement: Unosquare consultant embedded with the client's agile delivery teams.
Location: Nearshore remote (assumed: Mexico / Lat Am), working US Eastern hours.
Seniority: Senior, with 5+ years as a BA. Banking or payments experience is required.
Language: Fluent business English. The role is stakeholder-facing all day.
Headcount: 1 to start. The client mentioned possibly needing "a good analyst or two."

Why the role exists

Client has never had a BA function; a handful of senior engineers do the analysis, design, pre-sales, support and coding themselves, and that has become the bottleneck.

- Vague work reaches the teams. The platform was built by a few highly experienced consultant engineers who could take a one-sentence ask and run with it. Newer engineers can't, so they've been limited to UI work and bug fixes.
- No intake or prioritization process. There's no PMO, so "anybody can ask for anything at any given time." Leadership is building a list of every ask and everything in flight, but items are a mix of features, epics and stories with no consistent definition.
- Current behavior isn't documented. Feature calls get derailed "for the 100th time" rediscovering how things work today, such as roughly 25 permission levers across primary admins, admins and users with entitlements by payment rail.



A QA tester is the de facto expert because she had to reverse-engineer it.
- The client model has outgrown the product. Client platform now serves bank clients, vendors, third-party platforms and internal departments (internal teams are onboarded as if they were external clients). Requirements need someone who can say who is on the other end of each API, what they're doing with it, and how they authenticate.
- The product isn't defined well enough to sell. Sales pulls engineers into calls, and prospects misunderstand what the APIs do. One assumed they could send money from any bank to any bank. API docs say what an endpoint does, not who it serves or why.
- Sizing and capacity are guesswork. Story sizing is weak, so the team can't speak credibly to capacity or delivery dates.
- Audit exposure. Architecture diagrams (Lucid) and the platform wiki need to stay current as vendors and features are added, because the platform is subject to audit.

The client also wants to know how AI tooling can make an analyst more productive. This will be weighed against headcount.

Key responsibilities

The BA owns the space between the business's idea and the development team's sprint. Solution architecture stays with the bank's engineers.
Intake and prioritization





- Triage incoming requests and classify them consistently as initiative, epic, story, task, spike or defect.
- Run a lightweight preliminary assessment for each opportunity: client type, fit with the current product, t-shirt size, disruption, and the inputs leadership needs for revenue and risk decisions.
- Facilitate prioritization with stakeholders and push back when everything is labeled urgent, using team capacity as the anchor.
- Maintain the product roadmap and flag delivery risks, dependencies and blockers early.

Requirements and backlog

- Elicit requirements and write business requirements documents (BRDs) that stakeholders formally sign off.
- Break approved work into well-formed epics and user stories with acceptance criteria, permission and entitlement variations, and edge cases.
- Own the definition of ready. Run the pre-refinement review with the product owner, tech lead and QA lead so stories reach the team close to ready.
- Work with the tech lead or architect to sequence work and identify integration impacts on connected systems.

Product and platform documentation

- Reverse-engineer and document how client platform works today, starting with roles, admin types, entitlements and payment-rail permissions.
- Define the client and consumer model: bank clients, vendors, third-party platforms and internal departments, and how each is onboarded and authenticated.
- Write product-level API descriptions covering what each API does, who it's for and why it's useful to third parties, so sales and relationship managers can position client platform correctly.
- Keep the platform wiki and high-level architec

📌 9097 - Business Analyst Product Administration (México)
🏢 Unosquare
📍 México