As an L2 support engineer, you need to know WHAT your company sells and WHO is using WHICH product. That's the whole point of today.
Think of a restaurant menu. The restaurant offers many dishes — burgers, pizzas, pasta. Each customer orders something different. One table ordered just a burger. Another ordered pizza + pasta + drinks.
Now if a customer complains, the waiter needs to know exactly what that table ordered before helping them.
In fintech support, your company = the restaurant, products = the dishes, and clients = the customers. Your job as L2 is to always know: which client uses which product.
A Product Portfolio is just the full list of software products your fintech company offers. Each product does a specific job — like processing payments, detecting fraud, managing accounts, generating reports, etc.
Some clients use just one product. Some big banks use five or six together. Your job in support is to know this mapping so when a ticket comes in, you know exactly what system to look at.
The main engine of a bank. Handles accounts, balances, transactions. Everything connects to this.
Processes online payments. When you pay on a website, this product is doing the work behind the scenes.
Watches every transaction and raises an alert if something looks suspicious. Like a security guard for money.
Generates financial reports — daily transactions, monthly summaries, charts. Clients use this to see what's happening.
The app customers use on their phone. It connects to the Core Banking System in the background.
Checks that all transactions match up on both ends. Like making sure both sides of a receipt agree.
Think of a car. The car is the product. But it has separate parts — the engine, the brakes, the AC, the GPS. Each part does its own job. You can have issues with just the AC without the whole car breaking down.
Same with software. A product like a Payment Gateway might have modules like: Authentication, Transaction Processing, Notifications, Refunds, Reporting. A client might use all modules — or just some of them.
A Client Mapping Sheet is a simple document that tells you: which client uses which products and which modules — and in which environment.
When a support ticket comes in from "ABC Bank", you open this sheet and instantly know: they use the Payment Gateway + Fraud Detection, they're on PROD environment, and their key module is the Transaction Engine. Now you know where to look.
This sheet is your cheat sheet as an L2 engineer. Always keep it updated.
| Client | Products Used | Key Modules | Environment | Notes |
|---|---|---|---|---|
|
Alpha Bank
Retail Bank
|
Core Banking Payment Gateway Mobile App | Accounts Txn Engine Notifications | PROD UAT | High volume client. SLA: 2hr response. |
|
Beta Wallet
Digital Wallet
|
Payment Gateway Fraud Detection | Refunds Alert Engine | PROD | SaaS model. Vendor manages infra. |
|
Gamma Finance
Microfinance
|
Core Banking Reporting | Loans Dashboard | UAT DEV | New client. Still in testing phase. |
|
Delta Pay
Payment Processor
|
Payment Gateway Reconciliation Fraud Detection | Txn Engine Rules Engine | PROD UAT DEV | On-Prem. They manage their own servers. |
A ticket comes in: "Alpha Bank users can't receive payment notifications." — You open the mapping sheet, see they use the Notifications module of the Payment Gateway. You know exactly which system to check. No guessing.
Someone asks: "Does Beta Wallet have access to the Core Banking system?" — You check the sheet. Nope — they only have Payment Gateway + Fraud Detection. You answer in 10 seconds.
A new issue is reported on Gamma Finance's loan module — you check the sheet and see they're on UAT, not PROD. So this is a testing issue, not a live emergency. Your response priority is different now.
Someone from Delta Pay calls about a server issue — you check and see they're On-Prem. You know their IT team manages the servers, so you ask them to check their own infrastructure first before you dig into the application layer.