This blog post is a slightly edited version of my answer to the following Quora question:
What is the role of a business analyst in the payments domain?
I assume that the question refers to “payments technology” domain and consider the case of a Business Analyst (BA) who works for a tech vendor that provides payments products / services to Banks, Payments Solutions Providers and Corporate Finance / Treasury Departments. Examples of such solutions include Credit Card Management Software product and Bulk Payments custom developed software.
Per contra, this post does not concern itself with the role of a business analyst working in a Bank, PSP or Corporate Finance / Treasury Department.
With that bit of housekeeping out of the way, let’s dive into the role of a Business Analyst in Payments.
At the 30,000 feet level, a Business Analyst is the chief flagbearer of the vendor’s domain expertise. Assuming that her company is not involved exclusively in payments technology, it’s the BA who conveys to customers and prospective customers that her employer has enough domain expertise in payments. This can be a deal-clincher in both products and services since customers in a specialized space like payments like to engage with a vendor who can speak their language.
At the operational level, a Business Analyst is involved before and after the sale.
Presales
This phase happens before the deal is signed.
The BA engages formally and informally with payments products and payments operations people at the prospect company to
- Observe workflows and business processes
- Spark concerns about their efficiency, effectiveness, and cost
- Unearth pain areas with the status quo
- Describe how her company’s solutions can alleviate those pain areas
- Provide evidence of having done so at other companies
- Trigger the prospect’s thinking around potential solutions
- Carry out product / proof-of-concept demos
- Gather high level requirements
- Work out the solution and effort estimate
- Help sales to prepare a priced quote.
The BA owns some of the above activities and collaborates with her marketing and presales orgs on the others.
More on the informally part in a bit.
Implementation / Delivery / Customer Success
This phase happens immediately after the deal is signed.
It’s typically called implementation in an onprem product company; delivery, in a services company; and Customer Success, in a SAAS company.
As illustrated in the following exhibit, the Business Analyst plays a key role here.
As you can see, the BA’s involvement varies at different stages of the Software Development Lifecycle (SDLC).
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.
Just like “no man’s an island“, no new software can work in isolation. Any decent-sized bank, PSP or corporate finance department will have many existing systems and the new software must talk to them. For example, a new payments hub in a bank will need to send and receive data across the core banking software, sanctions screening solutions, and payments initiation systems in the existing IT landscape. Accordingly, it’s necessary to develop interfaces between the new software and the existing systems. It’s the BA’s job to write specifications for the interfaces. This could be the BA working for the product vendor or a third party systems integration company, depending on who develops the interfaces.
The BA also prepares the test plan for unit testing the software, once it’s developed.
The BA then gives a walk through of the above deliverables to the solutions architect and designer.
The BA has relatively little involvement in the next two stages of the SDLC when coders develop the software and testers carry out unit testing of the code based on the test cases provided earlier by the BA.
Once the code is released to the customer, the BA comes back to support the User Acceptance Testing. During this stage, business users test the build and log issues with it.
It’s the BA’s job to triage an issue as Feature or Bug.
- Feature is when the software behaves according to requirement / specifications signed off by the customer.
- Bug is when software deviates from the signed-off specs.
If it’s a feature, the BA specs the solution and helps the Client Engagement Manager to prepare a quote for a Change Request. Once the CR is approved, the BA goes back to the first step of gathering requirements. On a side note, I’d explained how a smart BA can use Change Requests as a key – only? – source of additional revenues in fixed price projects in Indian IT – Turning Crisis Into Opportunity: Part 2.
If it’s a bug, the BA fleshes it out in detail for futher action by her engineering team.
Production Support
It’s not often that a BA gets involved in the post-go live phase i.e. “production support” – but it does happen occasionally, especially immediately after go-live.
Payments is a very critical domain. If a payment misses cutoff, for example, $hit hits the fan, banks appear on the proverbial 6 o’clock news and regulators ask them uncomfortable questions.
Many issues can be resolved readily by production support folks. However, from time to time, a complicated problem comes up and a BA needs to step in to triage the problem, help craft the solution, carry out root cause analysis, and outline the steps put in place by her team to ensure that the same issue does not happen again in future.
To take an extreme example of the above, when I led the program to implement TARGET-2 at a Top 5 UK bank, the bank’s master data had 8 character BIC code. The new EU crossborder RTGS system used 11 character BIC code. When the system went live, all payment instructions with 8 character BIC bombed. As a result, many payments missed cutoff (memory serves, it was 3PM CET). This was at the height of the Great Financial Crisis, so the regulator called the bank’s CEO to inquire if the bank didn’t have enough liquidity to execute the missed payments! Not just the BA but even the Chairman of our company got involved in this incident. Days later, after this system stabilized, I saw it process a single payment of €282 billion with my own eyes!!
Informal
The term informally has been highlighted above for a reason.
There are many things that customers won’t elaborate during meetings. A good business analyst will develop a rapport with customers and engage with them informally, thus hoovering up more information than the customer has shared with her company in formal settings. This will help the vendor to design a more compelling solution. In politically-charged situations, it might be necessary to get the full picture even just to develop a passable solution.
A BA’s ability to glean more than the tablestakes information will not only determine the success or failure of a payments IT project but also shape her career advancement prospects.
Talking of which, the career path for a BA comprises Product Manager or Project Manager, Client Engagement Manager, and upwards, depending on whether they want to continue in a technical function or switch to business.
Business Analysts play a key role in the payments domain. In a nod to their salience in the success of a payments project, they’re often the most expensive resource on the project – next only to the program manager – and fetch 2-3X the billing rate of coders and testers.
Quora Link: https://qr.ae/pvwVbY
