Double entry accounting schema design
Most double entry accounting systems would implement this using 2 tables. One table that is the "header" table, which stores common fields &amp; a second "lines" table that stores the actual detail of the transaction. 

In case you didn't know, in double entry accounting, the sum of all transaction lines in a given transaction always adds up to zero.

Anyway, based upon your current design, I'd do something along the lines of:

Transaction
------------------
TransactionID
CurrencyID
Remarks
TransactionDateTime


TransactionLines
----------------
TransactionID
LineNo
UserID
DebitAmount
CreditAmount


To transfer $5.00 from UserID 100 to UserID 250, you'd have the following entries:

Transaction: 

10000, 'USD', 'Test transaction', '2019/09/15 12:34:56'

TransactionLines: 

10000, 1, 100, 500, 0
10000, 2, 250, 0, 500


You asked about a case where there might be multiple transaction lines:- To transfer $9.00 from UserID 100, with $8.50 going to UserID 123 &amp; $0.50 going to UserID 456, you'd have the following entries:

Transaction: 

10001, 'USD', 'Test transaction', '2019/09/15 12:34:56'

TransactionLines: 

10001, 1, 100,   900,   0
10001, 2, 123,   0,     850
10001, 3, 456,   0,     50


It doesn't matter from a mathematical/accounting point of view what order the lines are in, as long at the total is always net 0. 

Proper accounting systems would have a G/L Account column in each line, which would dictate where the transaction posted to, along with the posting period and other essential information at the header level. 

I'd seriously consider learning some accounting fundamentals if the system you're developing is dealing with real money.

This is obviously at a high level. If you require further help, please just ask.