Agreed. Any software engineer knows it shouldn't take much more than 1 second, tops for a number to be incremented in one computer and decremented on another, separated across a network. Roughly speaking. Now add in fudge factor to account for a long and possibly unreliable network path (the Internet cloud, or similar private banking inter-network) and for the need to perform an atomic and 100% bulletproof and auditable transaction, and we can envision a scenario where the total latency between when the request is made and when the deal is done and put to bed as say 1 day, tops. And that's being very generous on implementation complexity assumptions. So when I hear things like 3-5 days, a week, 2 weeks, that's getting into insanity land. I smell either really old skool legacy systems in terms of process and hardware capabilities, or, something fishy like a sneaky way to allow the middle-men to earn "carry interest", or whatever, during that bloated time gap. Possibly also some government regulation which adds an enforced, artificial delay. But in terms of what are the actual minimum technical requirements to carry out that task, a few seconds would be generous, an hour would be padded and a day's wait would be bloated to hell. I could even say a day if each bank wanted to run all transaction requests as a single batch performed nightly, with human auditors being able to look at reports both the day before and after to "sanity check" results. But again, that should cause a 1 day delay at worst.
I am not a banking programmer, so take with grain of salt. Perhaps there's some evil super-complex-and-unavoidable issue at play, but I doubt it.