Software and Hardware Requirements for an Exchange

Remember when you were a kid, and LEGO released their mystery box of random LEGO blocks with instructions that read, “Figure it out, kid.” No, of course not. Even a children’s toy company has more sense than that.

Building an exchange from scratch is no different. You may have assembled the world’s most killer team to run one, but if the parts aren’t there and if the instructions are missing, well, you might as well give up and go watch some cartoons.

As with LEGO, the parts you’ll need for an exchange each have their slot where they click right into place. And the reason we still call these little blocks, “LEGO” and not, “Jim’s Clicky-Block-Things,” is because of the care, quality, and clear instructions that go into each product.

So, let’s pretend we’re opening a fresh box of LEGO, with their separated baggies of related pieces, and crisply folded instruction booklet, and see how you might build an exchange that you’ll be proud to present, and your customers will be proud to use.

Baggie #1: The Bare Essentials

These are the big blocks that make up your base. Theoretically, all exchanges require, at a minimum:

• a market access interface and a market data interface
• a matching engine as the core of the exchange
• a data warehouse to receive and store all events taking place on the exchange
• a set of APIs to bring them all together.

Without them, all the little pieces of your exchange will topple over onto the carpet, waiting to get stepped on or eaten by the dog.

Instruction Booklet

Now, let’s see how to piece these all together.

In practice, functioning exchanges are not “bare bones”. Let’s use the above minimum requirements as a springboard and scale to the practical application.

• Market Access Interface

In practice, the market access interface is the order entry gateway for traders that will use your exchange. Most of the time, this gateway is a REST API or FIX protocol. Users will connect to this interface to create order instructions and receive order execution confirmations.

• Market Data Interface

Market data is distributed through WebSockets or TCP binary gateways that allow clients to subscribe to the exchange’s activity, connecting them with all that’s taking place on the exchange in terms of instrument price action or order books. Unlike market access interfaces (REST APIs) that support both sending and receiving, market data is a one-way connection.

• Matching Engine

The matching engine is the exchange’s core component that brings buyers and sellers together. The purpose of the matching engine is to enable price discovery, maintain order books for all traded instruments, and, essentially, to match buy and sell orders.

Selecting a matching engine, you need to decide what asset class your exchange is going to support. There are matching engines that cover a specific asset class (e.g. stocks, options, futures, etc) and there are also multi-asset matching engines such as DXmatch, that support multiple asset classes, including exotic ones, at the same time.

It’s also good if your matching engine supports industry-standard order types (e.g. Limit, Stop, Stop-Limit, Market) and provides low to ultra-low latency. It will come in handy if you are going to play the long game and scale your exchange in the future.

• Data Warehouse

The matching engine is a black box that processes all transactions in memory. Therefore, when your exchange receives an order, it has to be stored somewhere. You will need a data warehouse or a standalone module that receives and records all transactions and events that occur on the exchange. All reporting functionality will be linked to the data warehouse.

• APIs

All exchange components have to be interconnected via APIs to enable order placement, confirmation receipts, matching engine interactions, and access to order history.

Baggie #2: The UIs for your Exchange

If every LEGO set threw in the towel once kids had enough blocks to build the roads but no cars, a moon with no base, or an unpopulated forest, no one would buy them. So, why should an exchange be any different?

Your clients and your personnel will need user interfaces to work with your exchange. Of course, they might be savvy enough to enter orders and view confirmations via the command line. However, most users will still benefit from having a clear and understandable front-end to interact with the exchange.

These UIs are a must for every exchange.

A trading UI: A trading platform that provides end users access to the exchange’s trading functionality. For example, we at Devexperts have our DXtrade but you are free to purchase a SaaS platform, have someone build a custom platform for you, or even code your own platform.

We specialize in developing tailored, high-performance financial software that meets your unique needs. Whether you need a robust trading UI or a comprehensive, fully-integrated trading platform, our team of experts can deliver. Check out our financial software development services page and learn how we can elevate your trading capabilities.

An administrative UI: This user interface is designed for broker personnel. It shows exchange admins what’s going on – which instruments are being traded, what orders are there on accounts, what trades have been made over a specified period, etc.

A monitoring UI: This user interface is for your support personnel. It will show them the current status of software and hardware components, allowing them to deal with errors in time.

Surveillance UIs and back-office UIs are optional but still very welcome additions to an exchange.

With these added, we’re starting to see how the end product will soon match the picture on the box. Now for some of the essential small pieces.

Baggie #3: Third-Party Integration

This is the baggie where some of the most interesting pieces are found. What you’re building is taking shape into something beyond the standard model. Some small pieces require careful building. Then there are thin structural pieces that can only be used for one thing. Knowing where these go is as important as the pieces themselves.

If you are going to integrate your exchange with a clearinghouse, risk management providers, or other third-party services, you will need to work with their software and have REST APIs to connect to their external applications.

These third-party integrations run the gamut from custodians, clearinghouses, reporting and surveillance solutions, CRM, marketing and affiliate management, external news providers, analytics, and education solutions. It means that you’ll need to ensure that your basic components (such as the matching engine) support easy integration of third-party services via REST API.

Baggie #4: Hardware

We can’t ignore all aspects of building an exchange beyond the software since it needs to be physically hosted on a server. To select a suitable server configuration, you’ll need to answer a few questions beforehand.

• What are the regulator’s requirements for storage? 

It seems an obvious thing: your exchange is going to be regulated. Therefore, your approach to selecting servers will be based on your regulator’s requirements.

• What type and amount of data per month are you going to handle?

Select the server capacity based on the type of data your exchange will be processing. Another thing to consider is the number of messages per month.

• What network equipment will you need? Will you need backups?

You will need your exchange to continue even if one of the servers is down. There is a general shortage of server hardware due to COVID-19 and political unrest in the world, therefore, you need to get servers way beforehand. If you are planning to run capacity testing, you are going to need production-like hardware and production-like load.

• What server configuration will you need for hardware setups?

It is recommended to have several servers that would have more or less the same configuration, i.e. several processors, cores, memory, etc. You wouldn’t want a server zoo unless you want to run into problems with administering and replacing your servers. It’s best to find an optimal average between configurations by trial and error so that most use cases are covered.

• Should you select a cloud service or colocation?

Both approaches have their advantages. As a rule of thumb, for low to medium budgets, try cloud services. However, if you are planning to scale someday or your exchange prioritizes latency, it’s better to buy and administer your servers. If you control your set of servers, some more advanced system and hardware settings may become available to you, including settings required for an ultra-low latency network. There are cloud server providers (such as Amazon Web Services) that support basic ultra-low latency settings but you will need your own server park to apply the more advanced of them.

• Will you need a disaster recovery site and spare servers?

It’s easier when a disaster recovery site is required by the regulator. However, even if it is not, it is still better to have it to be on the safe side. If, for instance, an excavator damages a power cable in your primary data center, it is better to have a second identical data center with the same server configuration. It’s great to think about having some spare servers in case one is down. However, the major drawback to having spare servers and a disaster recovery site is the price.

Instructions: The Nitty Gritty Bits about Setting it all up

Every kid knows that click sound of a LEGO locking into place—and all have learned the hard way that trying to force pieces together the wrong way never ends well. So, here is all you need to know about the right way to set up your hardware.

The setup depends on the type of exchange. For example, most crypto exchanges at this time don’t seem to be overly concerned with latency. These markets are slower-moving with a great deal of retail involvement and don’t really need sub-200 microsecond order processing times.  They currently use web APIs, which are, by definition, not designed to be fast or low latency.

On the other hand, crypto exchanges prioritize availability and throughput. In these instances, cloud hosting is appropriate. At Devexperts, we employ clusters of independent but identical order processing units for availability. For throughput, we use horizontal scaling, splitting the instrument universe into multiple segments, each with its matching engine.

An example of a recent installation included over twenty Dell or HP standard servers with Xeon 16-core processors, SSD drives, and network cards with hardware acceleration.

Takeaways

And that’s all there is. If a children’s toy company has the foresight to cover all angles when instructing a kid how to build a model Millennium Falcon, surely no one should start building an exchange without the right instructions and the right pieces to click into place.

Different exchanges require different software and hardware setups. There are some basic components present in all exchanges but their specifications will vary depending on your budget, the type of assets you’re going to offer, your latency, availability, and throughput concerns, and, last but not least, your regulator requirements. Once you’ve mastered the instructors and familiarized yourself with all of the pieces, you can start thinking about these components as building blocks that can be twisted and turned every which way to find the suitable combination for your one-of-a-kind exchange.

We’ve been constructing matching engine components and fitting them into place for over twenty years. We’ve made the mistakes so you don’t have to; we’ve misplaced the instruction booklet, popped a few heads on backward, and accidentally knocked essential pieces under the sofa. We’ve even overused the occasional metaphor. However, this experience and deep industry knowledge have taught us all the essentials, along with a touch of flair, to build the best of the best—instructions or not.