I’m going to answer this question assuming it refers to “payments technology” domain. In this scenario, the Business Analyst (BA) works in an IT company that supplies payments IT products or services to Banks, Payments Solutions Providers and Corporate Finance / Treasury Departments e.g. Credit Card Management Software product company or Bulk Payments custom software development company. (In other words, I’m not going to take the case of a BA working in a Bank or PSP or Corporate Finance / Treasury Department.)
At the highest level, it’s the Business Analyst’s job to convey to customers and prospective customers that the Vendor has domain expertise in payments.
At the operational level, a Business Analyst gets involved in various activities before the deal (business development phase, presales phase) and after the deal (implementation / delivery / customer success phase).
Business Development Phase
The BA engages formally and informally with payments products and payments operations people at the prospect company; observes workflows and business processes; sparks concerns about their efficiency, effectiveness, cost, etc.; highlights pain areas with the status quo; provides evidence of using his company’s product / service to alleviate similar pain areas at other companies in similar situations; triggers the prospective customer’s thought process around solving the pain; shares new insights about payments in the prospective customer’s company or industry that the prospective customer did not know himself.
Presales Phase
Once the prospective customer is convinced about the need to do something about resolving their pain area, they shop around for potential solutions. This is done formally via the Request for Information (RFI) and Request for Proposal (RFP) documents / process. Once the vendor receives the RFI / RFP, the BA leads the following activities: parse through the functional requirements; flesh out the functional details; help the estimations team to develop the time and cost estimates of the stated requirement.
Implementation / Delivery / Customer Success Phase
Once the prospective customer places the order, the BA gathers detailed requirements from the customer via 1-on-1 interviews and workshops, writes them up in the form of specifications and requirements in documents variously called Blueprint / Business Requirement Document, and gets these documents signed-off by the customer. He also walks through the specs / requirements to solution architect and high level designers in his company. Once the code is cut and shipped to the customer, the BA comes back to support the User Acceptance Testing process carried out by the customer. During this phase, it’s the BA’s job to triage a defect logged by the customer as a real defect or “as designed” i.e. something that matches what the customer signed off earlier in the spec / requirement document. If defect, the BA explains it in detail to the engineering team. if it’s “as designed”, the BA helps the Client Engagement Manager to prepare a proposal for a chargeable Change Request. Once the CR is approved, the BA goes back to the first step in this section.
It’s not very often that a BA gets involved in the post-go live phase i.e. “maintenance mode” but it happens once in a while. Payments is a very critical domain from a customer’s customer and regulatory point-of-view. If a payment misses cutoff, the proverbial $hit hits the fan. In those cases, a BA does step in to triage the problem, help find a solution and assure the customer that “all is well”.