Why this weird API? I dunno, I would expect exactly two functions, one for sending a "file", and one for receiving whatever is new in the inbound queue, with the abstraction taking care of delivering the enqueued files to their destination!? And maybe a callback API so I don't have to poll for new inbound "files". Also, I'd expect the abstraction to provide an ordered, lossless stream, rather than some weird "file sync" which seems to lack all reordering and replay protection?
BankAPI
51–60 of 87 posts
Re: BankAPI
#52I don't think that's how banking works to be honest. Money move from bank to bank via the countries central banks if I'm not mistaken. Then the central bank reconcile everything in batch processes to ensure that banks aren't just making up money (well more than they are legally allowed to). Denmark has had a few occasions in the last few years where this has failed because one bank failed to deliver their transaction…
The money transfer between customers' accounts consists of two steps: The communication of the transaction records (who to debit or credit and what to print on their statement) and the settlement of the resulting total money transfer between the banks. The latter is what usually happens through the central bank, where both banks have accounts that are used to settle the total of all money movements between the two banks within a given period, in a single transaction between the two accounts. The transmission of the transaction records is independent from that and can happen in any way the banks see fit, including SWIFT (and sometimes the central bank, if it offers that service).
Re: BankAPI
#53I don't think that's how banking works to be honest. Money move from bank to bank via the countries central banks if I'm not mistaken. Then the central bank reconcile everything in batch processes to ensure that banks aren't just making up money (well more than they are legally allowed to). Denmark has had a few occasions in the last few years where this has failed because one bank failed to deliver their transaction…
IIRC, thats mostly done using SWIFT [1] [1] http://en.wikipedia.org/wiki/SWIFT_message_types
No, SWIFT is for international interbank settlements (transfers between commercial banks). Here's a description of the cumbersome process: https://bitcoinfoundation.org/2012/12/international-bank-tra...
The total balance of electronic currency in a commercial bank is tracked by the central bank of the currency in question (eg. the Federal Reserve for USD for the US, Danmarks Nationalbank for DKK in Denmark).
The Federal Reserve is the authority on the (electronic) USD balance of each US bank, and no non-US banks can have a USD balance (this happens via so-called intermediate banks where, for example, a Danish bank has a USD balance with a US "intermediate" bank).
Intrabank transfers (transfers from one account at a bank to another account in the same bank) is simply a change in that bank's local database. Interbank transfers (a transfer from one commercial bank to another) within the same country is handled by the central bank (since the central bank is the authority on the commercial bank balance of the currency they produce/manage).
Re: BankAPI
#54Earlier quoted context omitted.
IIRC, thats mostly done using SWIFT [1] [1] http://en.wikipedia.org/wiki/SWIFT_message_types
... for more background, SWIFT is an essentially global monopoly on international interbank transfers with all messages recorded in full by the US and its allies[1]. Despite claiming they only send messages, in effect money is moved and there are documented cases of it being seized off the wire by the US even in EU EU state transactions. It opened its first 'international center of operations' in Virgina (~CIA HQ) as…
> Despite claiming they only send messages, in effect money is moved and there are documented cases of it being seized off the wire by the US even in EUEU state transactions.
The ability of the US to seize USD transaction has nothing to do with any control they might have over SWIFT. All USD transfers -- even USD transfers between two EU citizens -- hapen via a US bank, because only US banks can have a USD balance.
The actual transfers happen by way of so-called US "intermediate" banks, who perform the actual USD transfer. The process is described here: https://bitcoinfoundation.org/2012/12/international-bank-tra...
Re: BankAPI
#55From the docs, I can't figure out how this is "decentralized". All I see are encrypted and compressed.
It should really say "peer to peer", which is more descriptive.
Re: BankAPI
#56This is a cool project, but considering how over-regulated banks are these days (at least in Europe) I think it's very unlikely that they would actually use this. Most bank software is still written in Cobol code that they have invested four decades into and are now too afraid to rewrite or even touch. So, specifying the requirements for an interbank message system would probably take them a few years already, and im…
> This is a cool project, but considering how over-regulated banks are these days (at least in Europe) I think it's very unlikely that they would actually use this.
According to Trustly themselves, it is used by 45 banks spread out over 7 EU countries (Sweden, Finland, Denmark, Estonia, Poland, Italy and Spain): https://trustly.com/en/#map-holder
Re: BankAPI
#57> 1. All parties MUST use a key length of 2048 bits for their RSA keys.
What is the point of this? Seems to me there'd be no problem in using 3072 bit RSA keys, which makes more sense given that the lowest security symmetrical encryption algorithm permitted for use is AES128, and the difficulty of breaking AES128 is roughly equivalent to breaking 3072 bit RSA.
Re: BankAPI
#58Earlier quoted context omitted.
Author here. That's a good question. Please see: https://github.com/trustly/bankapi/blob/master/doc/rationale...
> The decentralized design of BankAPI protocol ensures noone controls it, noone owns it, noone can shut it down, just like the Internet. The un-innovative design of BankAPI protocol ensures noone can critizise it, as there is nothing new invented, it's just a combination of existing well proven technologies. I don't think I'm comfortable with the 1960s singer-songwriter Peter Noone having this much control of your sy…
Re: BankAPI
#59With banks considering the switch to the Cloud, how would this specification address the issue of key management on the Cloud? That's the "key" to Cloud security. Currently, there are solutions available which are obnoxious for those who really want security of their data and not just a tick mark on some data security checklist because key managers CANNOT be hosted on the Cloud. The dominant approach (CipherCloud for…
A networked HSM is certainly one approach to solving this. Often, corporations -- not just banks or financial institutions -- will rent a cage in the same data center as the cloud provider, and will run a dedicated line from their cage to the provider. The networked HSM will store all key material, and whatever sensitive servers/databases/applications are provisioned in the cloud will leverage it for cryptographic op…
You forgot to capitalize "Cloud".
Re: BankAPI
#60This is a cool project, but considering how over-regulated banks are these days (at least in Europe) I think it's very unlikely that they would actually use this. Most bank software is still written in Cobol code that they have invested four decades into and are now too afraid to rewrite or even touch. So, specifying the requirements for an interbank message system would probably take them a few years already, and im…
> This is a cool project, but considering how over-regulated banks are these days (at least in Europe) I think it's very unlikely that they would actually use this. According to Trustly themselves, it is used by 45 banks spread out over 7 EU countries (Sweden, Finland, Denmark, Estonia, Poland, Italy and Spain): https://trustly.com/en/#map-holder
Huh. That seems to include all the (major?) banks in Finland. At least I don't know of a bank in Finland that isn't on that list.