Single-entry accounting schema
For your first question, that's an appropriate approach to balancing the Transactions. Every monetary change should be recorded as a Transaction. So at whatever rate you consolidate things like fraud, e.g. once a day (or as frequent as every minute, doesn't really matter as long as you record the Transaction for the consolidated amount every time) will result in how many of those kinds of Transactions to be generated.
To your second question, there's nothing inherently wrong with it being a one-to-many relationship, and business context aside, that's how I'd first imagine it. Bringing business context back in, normally a financial system in this space would handle these things through journaling. The concept of a journal is usually represented by two tables, JournalHeader and JournalLines. The JournalHeader represents generic information such as who created it and when it was created, whereas the JournalLines represent the individual Transactions consolidated via settlement. Usually there's a field on the JournalLines table that ties back to the original source of the transactions that were consolidated (generally another table, e.g. if there were SalesOrders that generated Transactions, the JournalLines would tie back to the original SalesOrder they consolidated). This relationship is one-to-many in nature, and standard.
I'm a little fuzzy on the exact implementation of such (as I haven't worked with that kind of finance in a while), but hopefully that helps paint the picture. Long story short, it is ok and normal practice to have a one-on-many relationship between the settling Transaction to its settled Transactions.