How will you restrict a user so that he is not able able to do daily trades [Interview question]

Today I was giving an interview and somebody asked me this question:

You are maintaining an online trading platform that uses spring based microservices. The platform is running on a distributed cluster environment. Given that the user can login from many different ip's or the user can do algorithmic trading i.e send millions of requests which are nano seconds apart. How will you restrict a user so that he is not able able to do daily trades more than $50,000 ?

I was totally clueless about this.  

So what is the best place to put this kind of validation.

Thanks.

In real world application, a user's authorization information is stored in a database table.
You may need to add a business logic like this psuedo code:
if a user's trade > 50 000 on today's date
   update the user's authorization to "No" in the database.

There are many different ways of doing it. That is just my opinion.  

There are two concepts of interest here: Authentication and Authorization (sometimes referred to as Authn and Authz, respectively).

Authentication is the process of verifying that the person accessing your system is a registered user and is using the correct credentials, i.e. the person attempting to authenticate as TraderBob is actually TraderBob. On a website this might be via a username and password challenge, combined with MFA perhaps. For algo trading, or HFT (High Frequency Trading), that might be via a system key based challenge. From the trading platform point of view that answers the question of who is placing the trade. Next is authorization, and that's the process of deciding whether TraderBob is allowed to do the thing he has requested. This is where your $50,000 limit check could be performed.

At this point I might venture into the performance implications of doing all these Authz checks prior to making a trade, but this statement tells me that performance is of little concern to the trading platform authors

an online trading platform that uses spring based microservices. The platform is running on a distributed cluster environment.

Although if we were to pretend that the trading platform was actually very fast, then I might propose that trading limit checks are performed post trade so as not to create a bottleneck in the order entry and matching process. Trades could be manually undone if it turns out TraderBob is operating wildly outside of his agreed limits, and if he persists he might find his Authn will start failing.

Just want to add this question was asked by a very senior technical person at Morgan Stanley and if you senior guys are not sure about this problem then where do I stand.  It definitely makes this question unfair to be asked in an interview.

It depends on the job you are interviewing for. If you are being hired to maintain a trading platform, I think that's a very fair question to ask.

It's a fair question, as Stephan says, if you're applying to work on a trading platform.

As with most things there are multiple valid solutions so they're not expecting to take your answer and put it right into production, rather they're just looking to see how you think about user authn and authz. Having worked on a trading platform myself I know one solution that has been proven to work, but that doesn't mean there aren't others equally as valid.

@Tim Can you share the solution ?

I'd disagree that this particular case is an A&A issue as it has business logic in it, and in fact, next week they might even demand a tiered system for different client subscriber levels. Rather, Authentication would generally be required to access the system at all, and authentication would determine whether the user was authorized for the role of trader.

Assuming that trades are in real-time, your best bet is probably to keep a daily total table for each trading user, and do a transactionalized gate of each incoming trade order. That is:

1. Lock the user daily trade record
2. Read and compare its current balance and see if the new request plus past history exceeds the allowed maximum. This is the business rule and, as mentioned, you might have to determine the limits based on user identity as supplied during Authentication.
   If so, FAIL the transaction
   Else, update the daily trade record and apply the request (all in the same transaction)
3. Finally, Unlock the user daily trade record

Housekeeping: Age out old history for each new day, which may be a batch process.

Depending on the overall system design, you might need to use XA-style transactions and not simple transactions.

Seriously ? For millions of parallel hits ? This can't be a scalable solution at all.

Simon Banger wrote:Seriously ? For millions of parallel hits ? This can't be a scalable solution at all.

Whose solution are you referring to?

If you're going to unconditionally block trades at the source, you either need a single-point database transaction or some sort of server that has the same effect, except for maybe keeping records in RAM.

Alternatively, you can load-balance across multiple servers by user ID, since presumably no one user is going to be submitting millions of transactions per second. You can spin elastic instances as needed in that case.

Simon Banger wrote:@Tim Can you share the solution ?

Unfortunately not, since financial trading companies get really fussy about such things. Sharing details about the matching engine that only a developer who worked on it would know could be viewed as insider trading, and I don't want to go to prison thank you very much.

If the requirement is to prevent a user from entering an order based on some account based criteria then you have no choice but to do up front pre-trade checks, then allow or deny the order entry based on the result. Something really simple to indicate whether the account is in good standing or not for a particular market, for example a boolean flag canTradeFX true or false. After every trade there can be some post trade process that updates the state of the account and sets that flag to false if some criteria is out of bounds, such as your daily trade limit.

In my experience, you don't have to perform such pre-trade checks. The trader signs an agreement with the trading platform operator before gaining access that outlines the markets they want to operate in and what margins they are allowed. Margins are usually based on how much money you can prove you have in the bank to pay for your trades. Like I said before, the account checks are done post trade (called clearing) and if you're operating outside of your agreed bounds then you have to explain yourself but often times still pay up. There are insurance policies available for serious errors of this nature, and there are many examples of trading houses going bust in a matter of minutes because of bad algorithms.

Performance is something you have mentioned but the presented architecture doesn't lend itself very well to high performance. For example, if you want your Java app to be very fast then Spring is a poor choice, just plain Java would be a better option. Then you mention "a distributed cluster environment" and oh boy there's so much to unpick there, but synchronising state across multiple instances and the unpredictability of network traffic adds an overhead that works in direct opposition to going fast. That doesn't mean you can't make use of multiple servers to operate your trading platform but you need to be smart about how you divvy up the work.

One of the other problems with networking is that packets arrive out of order from which they were sent, which for HFT traders is a problem because you can enter your order first but then miss out on a trade because your competitor's order overtook yours on the wire. It sounds ridiculous but I kid you not, it happens. Even within your Java application you need to be careful that order entry sequence is maintained, so be careful when using concurrency, threads, processes and the like.

Trading platforms are a very complex business, and there are many different ways to implement them. I expect the purpose of your interview question was to see how you think about the problem and kick you off down the rabbit hole of "what about this" and "what about that". The rabbit hole goes deep, I assure you.

If it was easy, everybody would be doing it.

Tim Cooke wrote:

Simon Banger wrote:@Tim Can you share the solution ?

Unfortunately not, since financial trading companies get really fussy about such things. Sharing details about the matching engine that only a developer who worked on it would know could be viewed as insider trading, and I don't want to go to prison thank you very much.

I think you've stretched the definition of "Insider Trading" a bit much. Insider trading is literally the process of buying or selling (or perhaps brokering) securities based on non-public information and if you really want to go to prison, get caught with a handful of marijuana or in a state where it hasn't been legalized. You'll get a much longer stretch than, say, if you'd tried to help overthrow the nation or done insider trading. Ask Martha Stewart.

On the other hand, disclosure of proprietary trading mechanisms will almost certainly get you hit with Theft of Trade Secrets and corporations can be even less merciful than governments.

Perhaps so, but I'm still not telling

Regarding to Tim Cooke's concern here:

 One of the other problems with networking is that packets arrive out of order from which they were sent, which for HFT traders is a problem because you can enter your order first but then miss out on a trade because your competitor's order overtook yours on the wire.

When requests are sent asynchronously, RabbitMQ/Kafka/ActiveMq is applied. But these tools do not guarantee the order of messages (requests) consumption when there are multiple consumers.
So, it is better to keep the communication between client and server stateless.

Trades should indeed be stateless. This is the kind of system for which ReST is extremely well-suited.

But bear in mind that there has never been a requirement that trades be processed in the exact order given. After all, there are still manual trades and humans work at a speed that's billions of times slower than bots. And that's not even counting instances where trades are originated or reciever literally simultaneously (which isn't always the same thing).

Automated trading systems are frequently housed as close to the exchange as possible to save nanoseconds on network latency, but at the end of the day, what's most important is that they be executed equitably.

And, indeed, bots have not all been held in high regard because, as I said, human trading speeds compared to bot trading speeds is inevitably inequitable. Regulations may apply.