Real-Time Use Cases in Capital Markets Part 2: Frontend UIs

As I mentioned in part 1 of the “Real-Time Use Cases in Capital Markets” series, I will be diving into four use cases covering pre-trade and post-trade processing. In the previous post, I covered market data/reference data distribution within the pre-trade umbrella and now I will be talking about frontend user interfaces (UI) for information displace and collecting orders.

Whether you are a hedge fund who places orders based on your strategies, a broker-dealer placing orders for their clients, or an investment bank with prop trading, you will most likely have a UI component responsible for placing those orders. The same UI might also be responsible for showing your positions, PNL, and risk associated with a portfolio manager’s portfolio and trading activity.

Focusing on investment banks, they offer their clients numerous ways to raise capital – clients can get access to primary markets and secondary markets. In primary markets, clients issue new securities such as bonds or equity through an IPO. Once they are issued in the primary market, these securities can then be traded by investors in the secondary market. An investment bank might have an internal system responsible for handling the primary markets and another for secondary markets. Both systems will have some sort of UI for clients, portfolio managers, and traders.

About a decade ago, these UIs used to be stand-alone which had to be installed on every desktop and upgraded regularly. Imagine doing that regularly at a large firm. Over the last few years, standalone web UIs have been replaced by HTML5 web UIs which are extremely portable and don’t require manual upgrades. Taking it a step further, a lot of financial firms have iOS and/or Android apps for their customers to manage their portfolios.

How Solace Helps with Frontend & Backend Applications

These frontend components typically leverage different set of protocols and APIs than backend platforms. Most modern frontend components typically leverage JavaScript as the preferred language and WebSockets as the preferred streaming protocol for displaying live data. Solace PubSub+ event brokers are ideal for such a setup because of their support for multiple open APIs and protocols out-of-the-box, without having to install any additional proxies or plug-ins.

Backend applications can distribute high-throughput, low-latency market data (as discussed in the last post) using backend technologies such as Java or C++ and Solace’s robust SMF protocol. And the frontend applications such as an HTML5 web-app can leverage JavaScript and WebSockets protocol to subscribe to the streaming data over PubSub+ brokers. As most brokerages have iOS or Android apps for their customers, these apps can subscribe and publish data to PubSub+ brokers via popular MQTT protocol.

Here is what that architecture would look like:

Figure 1: Application architecture consisting of both frontend and backend applications

Note the importance of fan-out here. The event broker supporting such an architecture needs to be able to fanout data to a large number of frontend users whether they be mobile users or desktop users.

Some key features of Solace that help in such a use case are support for both in-memory and persistent messaging, slow consumer handling, dynamic filtering, ACL profiles, message eliding, on-behalf-of (OBO) subscriptions, and caching. I’ll drill into each of the 7 features below.

7 PubSub+ Features that Support Frontend Components

1. Different Qualities of Service

A frontend component might need to display both live market data prices as well as be able to submit order data to backend applications. Both are very different use cases and require different levels of quality of service (QoS). Market data distribution is more suitable for in-memory messages, also known as “direct messaging” in PubSub+. With direct messaging, messages are never persisted so there is a possibility of some message loss. However, for market data use case, this is not a problem because direct messaging enables lower latency and higher throughput which is more valuable since getting the latest security prices as quickly as possibly is more important than getting every single price update.

On the other hand, when dealing with order data, every single message is of high importance. Order flow message rates are not as high as market data rates and do not have a tolerance for loss. For such data, PubSub+ supports “guaranteed messaging” where every message is guaranteed to be delivered via persistence to a disk. Support for both levels of quality of service makes Solace an ideal choice for a frontend component handling both types of data.

2. Slow Consumer Handling

Another useful feature is slow consumer handling. When you have multiple publishers publishing data at high message rates and multiple consumers the data needs to be fanned-out to, you do not want few slow consumers impacting the publishers’ ability to publish at those rates. Solace PubSub+ brokers have built-in patented technology that ensure slow consumers minimize impact to the healthy consumers and back pressuring the publishers.

3. Hierarchical Topics and Dynamic Filtering

As mentioned in other posts, Solace’s support for hierarchical topics and dynamic filtering is extremely powerful. Backend applications can publish market data for thousands of securities, but the frontend applications only need to show data for the securities that are in clients’ portfolio. It will be inefficient to subscribe to data for all of available securities and then have to filter data by the frontend application.

Figure 2: Sample topic taxonomy for market data use case

4. ACL Profiles

Additionally, Solace’s topics and wildcards can also be used for authorizing access to data. Clients’ trade flow is sensitive information that must not be exposed to other clients. Each client can be enforced to publish to their specific topics only for sensitive order flow and they would have authorization to subscribe to topics that suits their portfolio only.

For example, client #01928 has AAPL, IBM, and NVDA in its portfolio. Depending on how you design your topic taxonomy, here are the topics it might be restricted to:

Publishing new order data: 

• brokerage/orders/US/01928/newOrder

Subscribing to market data:

• marketdata/eq/us/nyse/ibm
• marketdata/eq/us/nasdaq/aapl
• marketdata/eq/us/nasdaq/nvda

5. Message Eliding

Not all subscribers require all the updates. Just because AAPL’s stock price is updating millions of times per day doesn’t mean the end-user needs to see all of those updates, especially since the human eye can only process at most 5 updates per second. For this reason, PubSub+ brokers support a feature called message eliding which allows end-users to define how they want to throttle. If a frontend client only needs 1 message per second, it can define that in its client profile so that it, as well as any other clients belonging to same client profile, will only receive 1 update per second.

6. On-behalf-of (OBO) Subscriptions

A key feature used by many PubSub+ users in capital markets is on-behalf-of (OBO) subscriptions. Solace enables a centralized subscription management architecture by providing a special feature which allows certain clients to subscribe and unsubscribe to topics on behalf of other clients. A subscription manager is a custom coded program running in the back end of your enterprise which manages subscriptions for other clients.

Figure 3: On-behalf-of subscription manager sequence

There are many benefits of using a subscription manager:

• Ability to use existing external permission system and ACL profiles
• Topic abstraction and encapsulation
• Dynamic subscription assignment
• Auditability

Consider a use case at an investment bank where there are 1,000s of frontend users (internal) logging into a web dashboard. They all have unique usernames and are entitled to different datasets. Typically, a large investment bank would already have a centralized authentication and authorization system. PubSub+ enables integration with these centralized systems via a subscription manager. The subscription manager will handle all the subscriptions and will communicate with the bank’s centralized authorization system to ensure appropriate topic subscriptions are mapped to a client’s session.

In market data use cases, there are popular entitlement systems provided by Refinitiv and Bloomberg. Refinitiv has DACS and Bloomberg has EMRS which are used to ensure users only get access to data that they pay for. A subscription manager can communicate with entitlement systems such as DACS and EMRS to ensure clients only subscribe to topics that provides them data which they have paid for.

White Paper: Accessing Real-Time Market Data in the Cloud with SolaceDelve into the business case for cloud-delivered market data; how an event mesh can help deploy that real-time data; and how to start the journey towards making it a reality for your organization.Download Now

By using a subscription manager, we are abstracting topic subscriptions away from the end users. They do not need to know which topics they need to subscribe to. This is particularly helpful when topic subscriptions change frequently. Additionally, subscription managers provide another level of security by not disclosing topics to the end users. For example, if your clients are external, you do not want to expose your topic taxonomy to them to avoid anyone reverse-engineering them. For example, imaging telling an end-user that they can subscribe to trade orders from Goldman Sachs by subscribing to topic: trades/banks/goldmansachs. A malicious client might reverse engineer this and start subscribing to similar topics such as trades/banks/hsbc which might provide them with unauthorized trade orders from HSBC.

Another benefit of using a subscription manager is auditability. A common requirement in many enterprises is to audit which applications have accessed which data. This might be for capacity planning, fee liability, security, or some other purpose. There are several ways to do this, including scraping appliance logs, listening to appliance events, or requiring applications to audit themselves. Each of these approaches have shortcomings. A simple way of producing effective and complete audit trails is via an OBO subscription manager. Since all client subscriptions go through the agent, it creates a single, custom coded place where you can easily log out all subscriptions made.

7. Caching

Finally, caching is a big requirement for frontend components dealing with market data. Frontend applications usually have requirements to retrieve the last value first and then subscribe to real-time updates in case there is no real-time data. For example, NYSE opens from 9:30am EST to 4:00pm EST. If a client application subscribes to JNPR’s data during this time, it will get real-time updates. But if an end user opens the application outside of this window, let’s say at 6:00pm EST, there will be no new updates for JNPR. During this time, the application would like to show the client what the last price was instead of showing an error or no value. For such use cases, Solace has an add-on product called PubSub+ Cache which is a separate software that works with PubSub+ broker to cache last values.

Figure 4: How PubSub+ Cache works

When subscribers connect to the broker and request data, they are first provided last values for those topics from PubSub+ Cache before getting live data (if available).

The consumer never talks directly to the cache but the requests are always proxied through the broker. This allows you to scale the caching layer independent of your consumers. Furthermore, the cache allows you to add ingress plugins in case you need to merge updates to build a full image of a market data update.

Conclusion

I hope my explanation of the seven features as well as its support for multiple open APIs and protocols (out of the box) explain why PubSub+ event brokers are ideal for a typical frontend setup.

Next up, I will be discussing pre-trade order processing, a key component of systems in capital markets, and the PubSub+ features that made it an ideal candidate for the use case.

Be sure to check out these next posts in the series as they are published:

• Real-Time Use Cases in Capital Markets Part 1: Market/Reference Data Distribution
• Real-Time Use Cases in Capital Markets Part 3: Pre-Trade Order Processing
• Real-Time Use Cases in Capital Markets Part 4: P&L Reporting and Risk Management