Overview
Having N number of BankAccount
objects should not matter in this scenario. There are a few situations that this implementation much be handled for so I will step through each one and explain the process.
Single-Server Application
The design would consist of Client's (the local application on the laptop) and the Server (the remote application handling the requests). Having multiple Client applications does not result in multiple Server applications thus allowing for synchronization to be handled on the Server. This way, a FIFO queue of incoming requests can be created, maintained, and executed as the Server sees fit.
In your family example above, the first arriving request will be processed first and receive a success notification. The other will be rejected and receive a failure notification.
Multi-Server Application
This is handled through Load Balancing. Luckily, there are implementations of this for Java. This will abstract away the multiple servers such that it looks as though there is a single server and the behavior is the same as the Single-Server Application. For a bit more on this issue, see this thread.
Database
The Database (DB) should implement either Optimistic or Pessimistic. Although Pessimistic has more integrity, it requires careful design, constant DB connection, and or a transaction id implementation in place of the DB connection. Optimistic could be used for application with a high-volume and no need for sessions, but in a banking scenario Pessimistic might be preferable.