Extending GraphQL in the BIQH Market Data Platform

In previous articles, we discussed the flexibility of the BIQH Market Data Platform and how our user interface supports configuration and control. In this article, we turn to the GraphQL layer that underpins the platform.

The BIQH Market Data Platform has always been designed as an API-first solution. Everything that can be done in the interface is equally available via the API. The interface itself consumes that same layer.

Clients are therefore not dependent on predefined exports or fixed feed definitions. They can connect directly to the platform and define how data is retrieved and structured within their own architecture. For this purpose, we use GraphQL.

GraphQL allows clients to specify precisely which data they require and how it is returned. This level of structural control is often considered sufficient. In practice, however, we found that structural control alone does not resolve many of the integration constraints encountered in financial environments. These constraints rarely originate from data availability, but from differences in representation, formatting and operational delivery across systems.

Defining structure at query level

A basic GraphQL query within the BIQH Market Data Platform looks as follows:

The response mirrors the query, returning only the requested fields without additional attributes. This means that the consuming system does not need to filter a predefined payload or reshape it afterwards.

The data contract is defined explicitly in the query itself. In integration projects, that predictability reduces ambiguity and simplifies downstream processing.

GraphQL also allows traversal of related objects within a single request:

In this example, instrument data and related listing currencies are retrieved in a single coherent response. In more traditional architectures, this would often require multiple calls and additional assembly logic. Defining the complete structure in a single query makes integrations clearer and easier to maintain.

Field aliasing further strengthens this level of control:

By renaming fields directly in the query, the output can align with internal naming conventions. Institutions with established data models do not need to introduce separate mapping layers solely to adjust field names. The API output already reflects the expected structure.

Up to this point, we are operating within standard GraphQL capabilities. During implementations, however, we repeatedly encountered challenges that were not structural, but related to representation and formatting.

Extending GraphQL beyond structure

Many integration issues do not arise from structure, but from formatting and representation. Date formats differ between systems. Decimal precision may be restricted. Boolean values often follow legacy conventions. Time zone differences can introduce reconciliation discrepancies.

Standard GraphQL gives clients control over structure. During implementations of the BIQH Market Data Platform, we found that clients also required control over formatting at field level. Rather than addressing these differences in middleware or downstream transformation layers, we extended GraphQL within the platform itself. Formatting decisions can therefore be defined directly within the query, ensuring that data is delivered in the required representation before it enters downstream systems.

The following examples illustrate how this additional layer is applied in practice.

Date formatting

Here, formatting is defined directly within the query. The same datetime field can be returned in multiple representations without introducing additional conversion logic elsewhere in the architecture. By controlling formatting at source, consistency is ensured before the data enters downstream systems.

Decimal precision

Decimal formatting is controlled within the query, ensuring that values enter downstream systems with the required precision. This avoids separate rounding logic that may vary across applications and reduces the risk of inconsistencies between systems.

Boolean representation

The same underlying boolean value can be delivered in different formats, depending on the consuming system. Providing this level of formatting control at API level removes repetitive transformation logic within each integration and ensures consistent interpretation across environments.

String formatting and constant values

String formatting can be applied directly within the query to enforce casing conventions. The @const directive allows fixed values to be assigned where required. The same mechanism can be applied to date and string fields when placeholder values or default identifiers are needed.

Time zone conversion

Controlling time zone formatting within the query prevents subtle reconciliation issues later in processing chains. By defining time zone handling explicitly at source, timestamps remain consistent across systems operating in different regions. For all datetime fields, you can specify in which desired timezone you would like to get the data output:

a: modifiedOn(timezone: “UTC”)

b: modifiedOn(timezone: “Central Europe Standard Time”)

c: modifiedOn(timezone: “Europe/Amsterdam”)

d: modifiedOn(timezone: “America/New_York”)

Managing and scheduling query definitions

In practice, queries within the BIQH Market Data Platform are not executed on demand alone.

Within the distribution layer, a defined query can be stored and managed centrally. The complete definition, including structural and formatting choices, is version controlled, scheduled and executed automatically. Structure, representation and timing are therefore explicitly defined, recorded and reproducible.

This means that a query is not only a technical request, but also an operational specification. What is delivered, how it is formatted and when it is distributed are all defined within a single controlled configuration.

For a more detailed explanation of this distribution layer, see our dedicated article on market data distribution:

Operational flexibility in practice

GraphQL gives clients precise control over structure. The additional capabilities within the BIQH Market Data Platform extend that control to formatting, representation and distribution.

Instead of placing transformation logic outside the platform, clients can define both structure and formatting directly within the query. This reduces architectural layers, limits duplication of logic and simplifies integration landscapes.

By combining structural control, formatting control and managed distribution, the query evolves from a technical request into an operational specification. What is delivered, how it is represented and when it is distributed are defined explicitly and reproducibly within a single controlled configuration.

The result is an API that not only delivers data, but adapts to the operational realities of financial systems. This allows institutions to integrate market data into their architecture with far less transformation effort and significantly greater control over how data is delivered.

Would you like to learn more about the BIQH Market Data Platform? Explore our interactive processing overview to see how these key market data processes are structured or get in touch with our team to discuss your requirements.