One by one, dealers embrace standardised FX reject codes

Investment Association’s proposed codes finally begin to take hold after Covid setbacks

Progress-on-reject-code-standardisation
Risk.net montage

Dealers are slowly adopting standard practices around codes that inform foreign exchange counterparties of the reasoning behind trade request rejections – so-called reject codes – which help them understand why a trade request has been unsuccessful.

A number of liquidity providers (LPs) – including JP Morgan, State Street and UBS – are starting to use a set of these reject codes proposed by the Investment Association to better inform counterparties about the reasons behind unsuccessful trading attempts.

“We’ve seen real progress being made within the last few months,” says Hugo Gordon, senior policy adviser for the investment and capital markets team at the Investment Association – a buy-side trading body with 250 members across the globe and £8.5 trillion ($10.5 trillion) in managed assets. “That’s been driven not just by the IA’s own work but also by the wider discussion around reject codes within the market.”

FX dealers have previously faced criticism from the Bank of England for not properly explaining themselves when declining to accept client orders. The most recent version of the FX Global Code now contains more specific language around providing reject codes.

“It should now be easier to assess why trades have gone wrong – making it easier to produce better outcomes for clients,” says Gordon. “By the end of the year, we hope we’re in a position where a good number of LPs are providing these updated codes to clients.”

A reject code is typically a numerical code or abbreviation that ­a liquidity provider sends to a counterparty making an unsuccessful trade request. If a counterparty’s trade is rejected due to a lack of credit, for example, the LP might send a reject code along the lines of ‘CR’.

One issue that has made it difficult for counterparties to understand what aspect of their trade might have caused rejection is the lack of standardisation used by different LPs in the FX market. Without a proper understanding of why trades have been rejected, counterparties can’t meaningfully change their trading behaviour to ensure a higher ratio of trade requests are accepted.

To help simplify this process, the IA published a February 2020 paper, in which it proposed 13 new standardised reject code categories.

Under these proposals, FX brokers, dealers and platforms are advised to use the 13 high-level categories to feed back to their counterparties when they reject a trade request. As well as helping to identify and remedy the cause of rejection more quickly, this will allow counterparties to better compare the behaviour of dealers during their last look windows.

Hugo-Gordon
Hugo Gordon, Investment Association

The IA gave LPs an initial deadline of the first quarter of 2020 to map their reject codes to its proposed categories and asked for feedback on their progress by the second quarter of that year. But the Covid-19 pandemic quashed the paper’s early momentum – and with it any progress toward standardisation.

“It’s fair to say that progress was relatively slow when we first published this paper back in February 2020,” says Gordon. “A lot of projects didn’t get the full attention that they might have previously received.”

So, in 2021, the group published a second paper, in which it restated its focus on the project and this time called on LPs to map their codes to its categories by the end of Q3 2021 – with full implementation to follow by the end of the first half of 2022.

Now, in addition to the aforementioned trio of dealers, a number of LPs are in the process of updating their reject code systems, notes Gordon, and are expected to have fully implemented the new codes within the coming months.

“We’re also aware of some other LPs that haven’t taken this work up as much as others and so we’re continuing to speak to them and are encouraging them to progress in this work as well – with our individual members continually engaging with these LPs on the issue too,” he adds.

Work in progress

For LPs that have yet to engage in standardisation work, technology constraints could well be playing a role in the delay, believes Stephane Malrait, global head of market structure and innovation for financial markets at ING. But he says these are not impossible to overcome.

“Some organisations rely heavily on external software vendors to upgrade their systems, and in that situation such upgrades can take some time. There’s a lot of testing that needs to be approved and conducted,” says Malrait. “But overall, updating your reject codes shouldn’t involve too much work. When an LP rejects a trade today there’s already a reject code being generated to clients – you just have to tailor the logic that is being applied to that coding system.”

One LP that has already standardised its reject codes is Credit Suisse. While not utilising the same reject code categories proposed by the IA – which are designed to act as guidance rather than prescriptive codes – the Swiss bank has already completed work to upgrade and streamline the reject codes they provide to counterparties after an unsuccessful trade attempt.

“We standardised our FX spot reject codes a few months ago to six or seven codes that can quite easily be deciphered and understood,” says John Estrada, global head of e-macro at Credit Suisse. “For example, our credit reject code is ‘Lack of Credit’, which is fairly self-explanatory to counterparties. We’ve tried to make our codes as easy to follow as possible as we’re very supportive of reject code standardisation – as are a lot of our counterparts in the market.”

JP Morgan, State Street and UBS declined to comment on their progress in this respect.

Besides the more specific language of the FX Global Code, Malrait believes another reason for the current progress on standardisation is that additional hold times during last look are no longer considered a valid reason for LPs to reject a counterparty’s trade request.

One of the main reasons people wanted more clarity around reject codes was because they felt LPs were “hiding things” in their last look practices, he says.

“Because of recent clarifications made by the Global Foreign Exchange Committee about what kind of behaviour is and isn’t acceptable during last look, a lot of LPs have removed their additional hold times and so don’t have anything to hide within their reject codes anymore – such as trades being rejected because of a price movement within a prolonged period of time,” he says. “That’s definitely one of the reasons why LPs are more supportive of reject code standardisation today.”

The Investment Association’s code categories

The following categories coincide with two phases of a trade’s cycle.

1. The quote phase – when investment managers request a quote, but:

Category A: Credit – the request is rejected because the credit limit of the client or its agent making the request is breached or not in place.

Category B: Pricing outage – the request cannot be processed because the pricing is unavailable.

Category C: Regulatory – the request cannot be processed due to regulatory requirements not being met.

Category D: Risk and capital constraints – the request cannot be processed as it breaches internal risk constraints, such as country concentration limits.

Category E: Static data – the request cannot be processed due to static data errors; for example, due to an error in the unique trader ID.

Category F: Unsupported product – the request cannot be executed because the request covers an unsupported product.

Category G: Exceptional – a residual category to ensure a complete set of categories exist and a reject code is always provided; only to be used exceptionally if none of the previous six categories is appropriate.

2. The trade phase – when a quote has been provided to an investment manager but the subsequent attempt to trade has been rejected:

Category A-1: Last look – because of the use of last look (including cover-and-deal), where a bank has imposed an artificial holding period that gives it a final opportunity to accept or reject the request against its quoted price.

Category A-2: Last look (latency) – after it has been last-looked due to inactivity, which may lead to clients attempting to execute on old pricing or liquidity that is no longer available.

Category B: Pricing/liquidity unavailable – because the client has attempted to execute the trade on a price or liquidity that is no longer available (because of inactivity, for example) and it has not been last-looked.

Category C: Credit – because the credit limit of the client or its agent has been breached or is not in place.

Category D: Static data – due to static data errors, such as an error in the unique trader ID.

Category E: Exceptional – a residual category to ensure a complete set of categories exist and a reject code is always provided, and only to be used exceptionally if none of the previous six categories is appropriate.

Editing by Louise Marshall 

Only users who have a paid subscription or are part of a corporate subscription are able to print or copy content.

To access these options, along with all other subscription benefits, please contact customer services - www.fx-markets.com/static/contact-us, or view our subscription options here: https://subscriptions.fx-markets.com/subscribe

You are currently unable to copy this content. Please contact info@fx-markets.com to find out more.

You need to sign in to use this feature. If you don’t have a FX Markets account, please register for a trial.

Sign in
You are currently on corporate access.

To use this feature you will need an individual account. If you have one already please sign in.

Sign in.

Alternatively you can request an indvidual account here: