The practice of using BPMS in the back office processes of the exchange

Where and why do we use BPM processes

The central part of the exchange is trading systems and their trading cores, in which the orders of market participants are matched and the order_log is formed

It is to the trading core (or rather to the gateway) that bidders connect. At the same time, in order for the trading system (TS) to work, by the beginning of the daily trading session, descriptions of trading instruments and descriptions of clients and their parameters for connecting to the TS must be included in it by the beginning of the daily trading session.

To describe these processes in a nutshell: they are long and complex.

Why is that?

Let’s give an example – let’s say a fraudulent company came to us, issued bonds, market participants bought these bonds, and the company, instead of fulfilling obligations to bondholders, transferred all the funds received from the market to offshore in the Cayman Islands and was like that. Who will answer for this? Who will be put in jail?

To avoid such situations, both when admitting financial instruments to trading, and when admitting participants in these trading to trading, KYC checks are performed for both, depending on the role in trading and on the market (for example, foreign exchange, stock, derivatives market ) – the processes by which the exchange will check the trading participant or the issuer of financial instruments will be different and will consist of different steps and different sets of checks.

All these processes take place in the back office systems of the exchange. Several divisions of the MOEX Group are working on KYC verification, and we entrust the orchestration and monitoring of these processes to executable BPMS schemes, and we arrange the follow-up logic in DMN notation.

This is convenient for the following reasons:

• The tools that we use are quite mature, they have solved the problems of ensuring stability and performance.

• Support tools are convenient and visual, easily transferred into the hands of the relevant support services.

• Development can be carried out quickly, and the toolkit can be expanded if necessary.

Our business is unique: there are hundreds of banks in Russia, and only a few exchanges, so a significant part of the development is exclusive and it has to be done on our own for ourselves, while we actively focus on opensource tools.

We started moving towards BPMS approximately from 2017, INITIAL STATE FOR 2017-18: the orchestration of processes between employees was carried out through the exchange of emails and filling out forms in applications. Some of the back office systems were written in outdated 4GL tools up to Paradox and FoxPro, some of the web applications were written as monolithic Java applications with their own state engines or mini-workflows written for private tasks.

Now we have our own back-office platform, which consists of the following elements:

1. Framework for managing the production process, metrics and quality.

2. Production platform including ci/cd, configuration and monitoring frameworks.

3. Centralized authorization, authentication.

4. Integration templates.

5. Unified technical services (notifications, business logging, process monitoring, scheduling of deferred and regular tasks).

More than 100 BPMS process diagrams work in combat. Any security of the Russian stock market enters trading through these processes. Any report on the results of the trading session from 2022 on the stock and currency markets is also orchestrated by our systems.

As a BPMS tool, the Camunda engine has taken root well, as one of the most mature and widely used engines of the Activity family. Mostly v7 is used due to transparent gluing with Java (a Java class is simply written to implement the machine task).

How do we get process descriptions

Business analysts, analyzing a task or project, communicate with the customer immediately using BPMN models, in most cases drawing them in camunda modeler.

The diagram immediately shows where the process starts, who is in what sequence and what they are doing, what are the options for completing.

In addition to diagrams, they write explanatory text, describe data, and everything else that is important. For me, as a development representative, this is a completely processable result, because. the main question in the corporate environment is resolved – who is responsible for what. All this is written in the wiki according to accepted templates, everything is convenient, full-text search works across the entire analytics database.

From an analytical BPMN scheme to an executable one – one step… but not always:

• If we do the process “within the same system” or “within the same network segment” – then you can take a logical circuit and modify it to an executable one;

• More often, the process integrates and orchestrates a chain of systems and then we do process cascading (management goes into sub-processes) and then developers, looking at documents and diagrams received from business analysts, develop physical executable process diagrams

  

What questions and problems do we solve, what do we face

BPMS-Processes that we develop and maintain are complex conduct during releases, manual regression testing of most processes is almost impossible. For this reason, both UNIT testing of executable circuits and automated testing of an integrated application through API and user interface are actively used.

If possible, we try to get away from long-lived processesso as not to incur the labor costs associated with migration or maintaining parallel versions.

Solved original technical problems several timessuch as developing custom plug-ins for the camunda cockpit. Cause: the need to support testing, setting process context parameters or activating timers in BPMS schemes by the tester’s decision, and not by the scheduled time.

Collecting custom tasks from all business processes into a single task manager: it gives the user a task exactly at the moment when the process has reached the task and it is assigned to the performer (or group of performers). The task manager does not have any business specifics, it simply displays the current active tasks of the user, while the developer of the business process is responsible for how a specific task will look and behave. Those. the task manager itself is one, but there are many processes that can display a task in it, and their development proceeds independently of each other.

In our work, we actively usecycle Plan – Do – Check – Act”and, with some frequency, after the implementation of a certain amount of functionality, according to the requirements of our customers, we ask questions:

1. To what extent do our development practices allow us to quickly and efficiently implement the requirements?

2. Are some of our approaches our limitations?

3. What can we bring to our infrastructure and development practices to develop faster?

Based on the results of the analysis, we make decisions on how to simplify and speed up.

Currently, at the corporate architecture level, we are working on defining a high-level business architecture of the Exchange’s end-to-end processes, in which the processes will be rebuilt as much as possible to work in the STP format: standard operations are processed automatically, the human task is to handle errors or “non-standard” situations.