Blame this one both the design adopted by the OT community and MySQL.
This is really not somewhere that I would consider any kind of SQL database server, and especially not one with as many flaws as MySQL. Possibly your problems could be solved with PostgreSQL but even that is not a good fit to this problem. You would do better to look for a solution based on message queueing where all transactions are messages. Make sure that you use/configure an MQ solution that guarantees delivery of messages. Then the app only has to get its transaction into an MQ broker, and your internal systems can take care of writing data to a datastore if necessary, and resolving conflicts.
However, be warned, that if you move to message queuing you will likely have to deal with issues such as serial numbers (similar to DNS zone serial numbers), timestamps, and resolving synchronization corner cases. But at least this is a well documented art. Usually this kind of code is hidden inside database server replication software and never revealed to the customer, but the computer science community has developed all the algorithms in the open, at conferences on Very Large Data Bases, and so on. Hunt for information on CiteSeer, follow up the citations in the papers you read, and you will find everything that you need to implement this yourself.
But please implement this in a modern language like Python or Scala first, and only if you really need to, translate parts of it to lower level C.
More on why I feel that MySQL is a risky choice for this use case.
You have asked about a scenario where synchronization of replicas is an important issue. I have seen so many issues with just master-slave replicas on MySQL 5.5 that I simply don't trust it. But don't trust me. Try two or thtree solutions and test them under load with your application. MySQL is fine for webapps that use the ActiveRecord design pattern, but other open source dbs do exist and are better for many scenarios. For anything as important as a dbms, you need to do comprehensive testing if you want to avoid suffering later.
A lot of people use a simple form of MySQL replication which basically sends a stream of commands from the master to the replica server. You can even chain this together so that the slave sends a stream of commmands onward to yet another server, perhaps one that is considered the "backup" copy and is never used for select queries or to replace a crashed master db. The problem seems to arise because not all commands will produce the same result when run on different servers. Commands using temporary files, random number functions and others, cannot be replicated. In addition I don't believe that MySQL enforces identical configuration on the replicas so you could get DDL that creates tables with different default character sets and sorting rules. Other databases have more replication systems but even Oracle can go haywire if its sequence numbers get munged up.
You are building a banking system and it could easily end up handling a much higher volume of transactions than the biggest New York banks, so the common Enterprise solution of an SQL database is probably not right for you. Tell your developers that they are working on a banking system and that it must be IMPOSSIBLE for money/objects to replicate themselves in multiple accounts. Give them the time and resources to build this system and tell them to read the research that is openly available, i.e. they do not have to reinvent the wheel, just implement it in a way that gives more control than a prepackaged db replication system.