[HN Gopher] How international money transfers work (2016) [video]
___________________________________________________________________
How international money transfers work (2016) [video]
Author : rjzzleep
Score : 154 points
Date : 2022-03-03 12:39 UTC (10 hours ago)
(HTM) web link (media.ccc.de)
(TXT) w3m dump (media.ccc.de)
| ck2 wrote:
| This is what russia is doing in response, taking their national
| system and making it international to end-run around SWIFT
|
| https://www.fxempire.com/news/article/central-bank-of-russia...
|
| If China joins it, that's going to be a problem.
|
| Then I wonder if the spy agencies are going to be able to monitor
| those networks like they do SWIFT
| RC_ITR wrote:
| >If China joins it, that's going to be a problem.
|
| Will it really be, though? China has their own system with
| CIPS, so if there's any joining, it will be Russia joining
| that. Then if Russia joins that, the West has a pretty strong
| political reason not to use it, then what you end up with is a
| controversial, lower-quality standard in competition with an
| already established standard.
|
| Like sure, Firewire was sort of a thorn in USB's side, but look
| who won.
| moasda wrote:
| Good video, it contains an explanation of SWIFT.
| [deleted]
| throw7 wrote:
| I'm confused on exactly what the swift ban is. In the video, it
| seems swift is just the "protocol" between banks and the central
| bank of the country you're in.
|
| At the end, he says international cross-currency transfers are
| done through "intermediate" banks like jpmorgan that has an
| account from a bank in the country you want to send to.
|
| So I'm unclear what the "swift ban" did and exactly how it
| affected russia? Do the international transfers still use the
| swift protocol?
| boringg wrote:
| As I understand it - their Russian banks endpoints have been
| disabled (except those who are doing gas and oil sales are
| still active as that hasn't yet been blocked). Think of swift
| as a plumbing network with specific endpoints being available -
| if you aren't on the network then you aren't able to transact.
|
| Probably could have used something more internet related than
| plumbing.
| elevenoh wrote:
| How are endpoints disabled?
|
| Is this the case: nodes on SWIFT network need to update their
| code to block an endpoint like Russian banks?
| briodf wrote:
| I'm the co-founder of a international money transfer comparison
| engine, AMA if you have questions about international money
| transfers from a consumer perspective.
| cuchoi wrote:
| Love monito.com! Congratulations on your product. Do you know
| why so many money transfer system have restrictions on the
| directions to send money? For example, Wise only allows sending
| in the USA (USD) -> Chile (CLP) direction but not the other way
| around. Also Moneygram only allows USA -> Chile and it is
| blocked from non-US IP adresses.
| briodf wrote:
| Thanks!
|
| This is likely a combination a question of Money
| Transfer/Transmitter License & compliance, but this is not my
| area of expertise. A provider like Wise is licensed in the
| countries where it accepts customers. In this case, Wise is
| licensed in the US but not in Chile:
| https://wise.com/help/articles/2932693/how-is-wise-
| regulated...
|
| As it's a costly and complicated endeavour, they must
| prioritise the markets they operate in and must have made the
| business decision not to be licensed in Chile as of now.
|
| Luckily, Monito always try to find local companies filling
| the gap of big players, and Global66 is an interesting
| alternative from Chile: https://www.monito.com/send-
| money/chile/united-states/clp/us...
|
| Moneygram is likely limited in accepting US residents with
| their US site for similar reasons.
| bko wrote:
| Two questions:
|
| - The video talks about a suspense account, basically locking
| your money prior to it being netted out against others and sent
| to the central bank. How often do these take place? How does
| that relate to my checking account having money as "available"
| as opposed to deposited? In general, which step is responsible
| for money transfer taking so long?
|
| - What prevents me from going to two ATMs at exactly the same
| time and withdrawing my entire balance? Is there a single
| central location for instantaneous money transfers like ATMs?
| briodf wrote:
| Two excellent questions, which I am unfortunately not able to
| answer with confidence, as it goes into the weeds of payment
| rails& infrastructure. Someone actually making the transfers
| (instead of a comparison site like us looking at the
| available services and recommending you the best one for your
| needs) would probably have the answers.
| retrac wrote:
| > What prevents me from going to two ATMs at exactly the same
| time and withdrawing my entire balance? Is there a single
| central location for instantaneous money transfers like ATMs?
|
| I am a bit familiar with Interac in Canada, the EFTPOS (pin
| and chip retail) system here. Aside from the EFTPOS system,
| it also serves as a domestic interbank transfer service. When
| you withdraw money from an ATM, the ATM bank connects to your
| bank via the interbank Interac system, and submits your
| authorisation to transfer the funds out of your account into
| the ATM bank's receiving account and gives you the money.
| This is an atomic transaction done real time, so no double
| spending allowed. I believe it's conceptually quite similar
| for the European EFTPOS systems and Cirrus/Maestro in the US.
| Credit cards work a fair bit differently though.
|
| And yes, the transfer from customer to merchant is in fact
| usually immediate. If someone buys something in my store, I
| can 10 seconds later use the debit card linked to the account
| to spend the funds. That's why reversing fraudulent debit
| card transactions can be a major pain with not much in the
| way of guarantee of restitution.
| bko wrote:
| Does this mean there's a central server / database every
| ATM for a particular bank queries?
|
| I'm thinking if there are multiple servers you could
| theoretically do it at the exact same time. Or if there are
| multiple servers but one database, is the database locked
| for your account when performing the request?
| retrac wrote:
| Yes. Each bank provides an access point to the interbank
| network. Which is a fairly centralised service run
| collectively by the participating banks. There's one
| database (approximately) per bank. That holds your
| account figures, etc. Atomic transactions are used, so
| yes, the account is locked on both ends until the funds
| go through or the transaction fails.
|
| In the early days (1980s, 90s) this all tended to crash
| on Black Friday and Boxing Day, taking the whole thing
| down for entire banks and, a few times, nationwide. Been
| a good 20 years since that happened regularly though.
| anonporridge wrote:
| What's being described here sounds very analogous to the bitcoin
| lightning network, as Jack Mallers describes to the IMF here,
| https://www.youtube.com/watch?v=jb-45m9f76I
| yeetard wrote:
| god bless the ccc
| 7373737373 wrote:
| Under which circumstances, and how, is money ever _physically_
| transferred? E.g. with international transfers - unless the
| netting cancels exactly out, or there is an already funded
| account at a correspondent /intermediary bank - there has to be
| cash transported at some point. It'd be understandable if this
| only ever happened between large, international banks which
| smaller banks are usually customers of. Other than depositing at
| the central bank and providing cash withdrawals, does cash ever
| enter the equation?
| manholio wrote:
| saul_goodman wrote:
| Very interesting, and the Bankers Almanac was something I'd never
| heard of before. We're all used to PayPal/Stripe/etc. working
| instantaneously because it's already inside the US system. While
| SWIFT seems decrepit, it explains how much trust is involved in
| banking; more-so for international banking. If there was not a
| person in the middle of international transactions banks would
| face a lot more potential fraud. If your bank went out of
| business because they participated in some dodgy international
| transactions you would be rightfully pissed off at losing all
| your money.
|
| The Bankers Almanac also helps explain how "legit fraud" takes
| place, ie: how money can move around sanctions. It seems clear
| that by cutting Russia off from SWIFT probably stifles unrelated
| 3rd parties from moving around other road-blocks. Could also be
| something helping to clear the path to CBDC's: by removing major
| exit points to "Freedom Dollars"/cash.
| rjzzleep wrote:
| What you consider a feature I consider a bug. Whatever was the
| predecessor of SWIFT was, was probably not intended to cut
| people off of international settlements, it was intended as a
| way to establish trust between otherwise untrustworthy parties.
| It's kinda to normal banks what the BIS(bank for international
| settlements) is to central banking.
|
| The very fact that one party can bully others to completely
| shut off parties from international banking is probably not
| what a lot of countries thought when they joined the system.
|
| The Chinese' CIPS actually uses the SWIFT messaging system
| underneath, although I imagine China to be as neutral as the
| US/SWIFT when their own interests are at risk.
|
| As much as I dislike Crypto what it is today, in a way the idea
| behind it is supposed to decentralize the trust system that is
| at the core of SWIFT. Otherwise you should consider that the
| only way you can have a truely neutral settlement party(i.e. a
| neutral SWIFT), is if it is run in a country that is strong
| enough to have a fully independent economy(already unlikely)
| and has enough military power to support itself. But then the
| latters interest in global power would probably directly
| interfere with the concept of neutrality.
| elsjaako wrote:
| You mention cryptocurrencies as an alternative. But many/most
| of these have an open ledger. Isn't it possible for a
| government to sanction certain bitcoin accounts, making any
| bitcoin coming from them either worthless or less valuable?
| almostkorean wrote:
| That is mostly correct and a big issue with crypto in its
| current state IMO. If government blocks your off-ramps,
| it's possible you could still sell via a bitcoin ATM or
| find someone to do an OTC trade but those are obviously not
| ideal.
|
| If we are talking ETH, it's possible to use zero knowledge
| proofs to send money and make it impossible to trace back
| to the source (see https://tornado.cash/). This also has
| some limitations, like you wouldn't be able to tornado 8
| figures worth of ETH but certainly better than an OTC deal.
| It's also possible that the off-ramp exchanges could block
| any ETH that was sent through tornado. This gets hairy
| pretty quickly though, as the tornado ETH could easily be
| wash traded or mixed. Or it could be used legitimately,
| swapped for stablecoins, etc.
| secabeen wrote:
| > What you consider a feature I consider a bug. Whatever was
| the predecessor of SWIFT was, was probably not intended to
| cut people off of international settlements, it was intended
| as a way to establish trust between otherwise untrustworthy
| parties. It's kinda to normal banks what the BIS(bank for
| international settlements) is to central banking.
|
| > The very fact that one party can bully others to completely
| shut off parties from international banking is probably not
| what a lot of countries thought when they joined the system.
|
| I don't know if that was necessarily the case. SWIFT was
| founded in the 1970s, during the cold war. I doubt any bank
| or country attaching to SWIFT expected to be able to use it
| to transfer money into the Soviet system. I can't find any
| easily available history of Russian connection to SWIFT, or
| whether that was before or after the fall of the USSR.
|
| I would expect that any bank participating in SWIFT would
| expect that it is reliable and durable throughout the West,
| but that using it to connect with what used to be called the
| Second World would be best effort only, and could be cut off.
| [deleted]
___________________________________________________________________
(page generated 2022-03-03 23:01 UTC)