← All articles

Mikhail Polyakov

Systems analysis at a bank and a large fintech company: how the job differs and what changed in 2026

Level: IntermediateReading time: 12 min

Topics: Systems analysis, Fintech

A bank building, a server, office buildings and a cloud with servers connected by glowing lines with coins moving along them, and a lock shield at a fork

The short answer: a systems analyst at a bank does the same work as at any other company. They translate "what the business needs" into how the systems are built: what data is involved, where it is stored, who passes what to whom and what happens when something fails. The difference is the cost of a mistake and the number of external rules. An analyst in fintech thinks ahead so that money is not lost and not debited twice, describes the exchange between many systems and takes into account the Bank of Russia's security requirements and the personal data law. Since 1 September 2026 the largest banks have been required to offer their customers digital ruble operations, and that is also work for analysts. Below I go through what this work consists of, what to learn and how to tell whether it suits you.

I have worked in the financial sector since 2020: first at asset management companies, then in the brokerage arm of a banking group, and now as a chief systems analyst. The examples below come from this experience, without internal details of my employers.

Who a systems analyst is

The profession has a professional standard, approved by Russia's Ministry of Labour in 2023 (order No. 367n, valid until 2029). Put in plain words, the analyst's task under the standard is to make sure a system matches the original requirements and the environment it works in, and to develop clear design decisions for that. The standard divides the work into four levels: from technical support of design to leading a team of analysts.

In practice, the result of an analyst's work is a set of documents the team uses to write and test code:

  • requirements: what the system must do and under what conditions;
  • a diagram of the exchange between systems: who calls whom, in what order, what comes back;
  • a description of the programming interface (API): which fields, which formats, which errors;
  • a data model: which tables and links are needed, how much data to keep;
  • error scenarios and acceptance criteria: how to tell that the work was done correctly.

A business analyst answers the question "what is needed and why". A systems analyst answers the question "how to build it in our systems". In some companies this is one person, in others two different roles.

Five ways work at a bank or a large fintech company is different

1. Money must not be lost or duplicated

In an online shop, an email sent twice is annoying. At a bank, a transfer sent twice is the customer's real money. That is why an analyst in fintech describes not only the successful path but everything that can go wrong between systems:

  • no reply came from a neighbouring system: can the request be repeated, and how to avoid processing the operation a second time;
  • the operation went through in one system and failed in another: who brings everything back into a consistent state, and how;
  • how to check at the end of the day that the amounts in all systems match, and what to do if they do not.

There are well-known techniques for this: a unique number for each operation, so that a repeat is recognised as a repeat; operation statuses that can be checked at any moment; regular reconciliations. An analyst must know these techniques and spell them out explicitly in the requirements, otherwise each developer will solve the problem in their own way.

2. Many systems, and all of them connected

A single feature visible to a customer at a bank can touch several systems at once: account records, a payment gateway (receives payments and passes them on), anti-fraud (looks for fraudulent operations), reporting, notifications. At an asset management company I did the analysis from scratch for a model portfolio system, and it ended up with more than 20 integrations with the company's other systems. A large part of an analyst's work here goes into agreeing with the owners of neighbouring systems on formats, deadlines and who is responsible for what when something fails.

3. Load and data volume

Brokerage and payment systems handle a large flow of operations and keep history for a long time. In my current job I did the analysis for splitting tables into parts, moving to the cloud and deleting outdated data in systems with a load of more than 1000 requests per second. Such questions exist in a small system too, but at this volume a wrong answer costs noticeably more: how much data is added per day, which of it can be deleted and after how long, what will break in neighbouring systems if a record moves.

4. Some of the requirements are written by the regulator

A bank works under the rules of the Bank of Russia, and some of the requirements for a system come from there rather than from the business. An analyst does not need to know all the regulations by heart, but does need to know which of them apply to their task, and to bring in security specialists at an early stage.

An example of such a rule: Bank of Russia Regulation No. 851-P (it replaced Regulation No. 683-P, which many people know). Under it, applications that a bank gives customers for operations, and programs that accept customer instructions over the internet, must be certified by FSTEC or pass an assessment at a trust level of at least OUD4. FSTEC is the state regulator for information protection, and OUD4 is an evaluation assurance level: it shows how thoroughly the program's security has been checked. The same regulation requires checking the infrastructure once a year for the possibility of a break-in and looking for vulnerabilities. For an analyst this means: a new customer feature goes through security checks, and that time has to be built into the plan.

If a bank counts as a procuring entity under the federal law on procurement by certain types of legal entities (223-FZ) and a system is recognised as a significant object of critical information infrastructure, Presidential Decree No. 166 also applies: since 1 January 2025, foreign software may not be used on the significant objects it owns, unless a federal law provides otherwise. In that case, when choosing any library or service, the analyst checks where it comes from.

5. Personal data is expensive

A bank knows almost everything about a customer: passport, income, operations. Since 30 May 2025 increased fines have applied for personal data leaks, and their size depends on how many people and records are affected. If the leak is a repeat one, that is, the company is at that moment already considered to have been punished for a previous one, Article 13.11 of the Russian Code of Administrative Offences provides for a turnover-based fine of 1 to 3%. For an ordinary company it is calculated from annual revenue, and for a bank from its own funds (capital) on the date of the violation. The lower limit is 20 million roubles (part 15), and if special categories of personal data or biometrics leaked, 25 million (part 18). The upper limit in both cases is 500 million. The analyst decides which data a feature really needs, whom to show it to, where to hide it and what to write to the log. The principle is simple: do not pass a field to a neighbouring system if it can do without it.

What changed in 2026

The digital ruble. The law No. 248-FZ on phased connection to settlements in digital rubles came into force on 1 September 2026. According to Alla Bakina, director of the Bank of Russia's national payment system department, by that date all 12 systemically important banks, which account for more than 80% of the payment market, were ready to let customers open digital ruble accounts and carry out operations. Another 9 banks that are significant in the payment services market are also connecting, and three of them need time until the end of the year.

The law also brings in sellers in stages, and only those who sell goods and services to individuals for personal needs. According to the Bank of Russia's explanations, the following must accept digital rubles:

  • no later than 1 September 2026: sellers with revenue for the previous year above 120 million roubles that, as of 1 January 2026, had an agreement on accepting electronic means of payment (for example, acquiring) with a bank that the Bank of Russia has recognised as significant in the payment services market;
  • no later than 1 September 2027: sellers with revenue above 30 million that, as of 1 January 2026, were customers of a significant bank or a bank with a universal licence under such an agreement;
  • no later than 1 September 2028: other sellers with revenue of 20 million or more.

Companies with revenue below 20 million are not required to accept digital rubles. Nor are retail outlets with annual revenue below 5 million, even if they belong to a large company, or points of sale without internet access.

For an analyst, this is a new external system to which applications, cash registers, accounting, reporting and reconciliations are connected. And new questions of the same kind as in the first section: what to do if the platform did not respond, how to reconcile balances, how to show the customer the status.

Open APIs. The Bank of Russia has long been preparing common rules under which banks, with the customer's consent, exchange that customer's data through standard interfaces. In December 2025 the Bank of Russia approved 10 standards, and about 20 banks and companies are testing them on the Association FinTech platform. In October 2025 the Bank of Russia postponed mandatory implementation until a federal law is passed. As of July 2026 the law has not been passed and the exchange remains voluntary; the Association FinTech and the largest banks are asking the Bank of Russia to speed up its adoption. An analyst who joins a bank now would do well to read these standards right away. Whether integrations based on them become mandatory, for which banks and from what date, will be decided by the text of the law once it is passed.

What a task looks like: a simplified example

Suppose a customer needs to move money from a brokerage account to their own bank account directly in the app. This is a simplified example, without the details of a specific bank. The analyst goes roughly along this path:

  1. Finds out from the business exactly what is needed: which accounts, which limits, at what hours, how long the customer waits for the money to arrive.
  2. Finds all the systems on the money's path: the app, brokerage records, bank records, the fraud check, notifications, reporting.
  3. Draws the exchange diagram: which system calls which, in what order, with what data.
  4. Describes the behaviour on failures: the brokerage system debited the money, but the banking system did not respond. What the customer sees, how not to process the operation twice, who sorts out stuck transfers and when.
  5. Checks the requirements with security and compliance (the function that makes sure laws and Bank of Russia rules are followed): which checks are needed, which data to write to the log, who sees the operation.
  6. Writes acceptance criteria: which checks will tell the tester and the business that the work was done correctly, including failure scenarios.
  7. Stays with the team through development and testing: answers questions, refines the requirements if reality has diverged from the document.

In my experience, the most expensive mistake in such a task sits in the fourth step: everyone sees the successful path, while a failure between two systems is noticed once it has already happened to a customer.

What it pays

According to Habr Career for the first half of 2026, the median salary of a systems analyst is 222 thousand roubles a month. By level: junior 109 thousand, middle 200, senior 303, lead 362. These figures cover all industries; the study has no separate figure for banks and fintech, so for a specific vacancy look at the range in the job ad itself.

What to learn and how to test yourself

If you want to move into systems analysis in fintech, here is what gives the greatest return:

  • SQL. Read data yourself and test your hypotheses without a developer.
  • Integrations. How systems exchange data. HTTP requests and REST: one system calls another and waits for a reply. A message queue: one system leaves a message, and another picks it up when it is ready. And how synchronous exchange, where the reply is awaited right away, differs from asynchronous exchange, where the reply comes later.
  • Diagrams. Sequence diagrams (who calls whom) and business process descriptions, to show the logic without ten pages of text.
  • Reliability of operations. Retries, unique operation numbers, statuses, reconciliations.
  • Regulation, to the extent your task needs it. Read at least Regulation 851-P and understand what personal data means under the law.

How to test yourself: take any service you know, for example a transfer by phone number at your own bank, and describe it as an analyst would. Which systems take part, what is passed between them, what happens if one of the participants does not respond, how the user learns the result. If you have no answer to the fourth question, you have found what to learn next.

When this work will not suit you: if you are not interested in figuring out other people's systems and reaching agreement with their owners, if approvals with security and long checks before a release irritate you. At a bank there is no way around them; they are part of the process.

If you are on the business side

If your company is connecting to a bank or a fintech service, for example for payments or for the digital ruble, the analysts' work on the other side will go faster if you prepare in advance:

  • a list of the data you are ready to pass on, and what each field is for;
  • a description of what your system does if the bank did not respond or responded with an error;
  • a person who is responsible for the integration and can make decisions quickly;
  • a time buffer for security checks on both sides.

I have a separate piece on what AI changes in protecting websites and servers: can AI hack a server or a website.

Summary

Systems analysis at a bank and a large fintech company is the same profession with a higher cost of mistakes. The analyst describes not only how everything works but also what happens on a failure, keeps dozens of connected systems and the regulator's requirements in mind. In 2026, digital ruble operations at the largest banks were added to this, while mandatory open APIs, as of July 2026, are waiting for a law. If you like figuring out how things work and seeing awkward scenarios through to the end, this is a good place to grow.

I work in systems analysis in finance, AI agents and automation. If you would like to see my projects or discuss your own task, take a look at my portfolio.

Sources