mTLS would be sufficient and honestly more than enough, it sounds like. Plain TLS (client validates the server) will encrypt all traffic in transit end to end, using appropriate handshakes and symmetric cyphers. Anything using RSA directly will be significantly more likely to be incorrectly implemented and thus worthless.

mTLS would allow you to trust a CA per user, a cert per user, or issue your own keypairs for clients, depending on the use case. You validate the connection and look up the client based on some certificate field like CommonName or any of the other fields.

Then you've authenticated, and you can perform authorization for any transactions on that entire connection, plus you know for certain if it was MITMed it was done by someone with access to keys trusted by both parties.

So what part are you wanting to protect?
The user to your client? The client to you? Or essentially end-to-end between the user and you, but via your client?

Perhaps an alternative way?
The user sends the stock pool to the client, they give the user a transaction key. The user submits the transaction key to you, you fetch the transaction details from the client, then you process them?

I guess I'm failing to understand why the payload needs to be encrypted everything is already travelling over an encrypted medium (IE TLS/HTTPS).