Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Griffin – A fully-regulated, API-driven bank, with Clojure

juxt.pro

Post reply on HN
Print view View original

51–60 of 223 posts

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#51

Post by hakfoo »

siftrics wrote: post #48
epolanski wrote: post #44

Earlier quoted context omitted.

The issue is always the same: traditional banking is frictionless, very cheap and convenient for 99.9% of people out there. Crypto isn't frictionless, it's not cheap and it solves problems that only the 0.1% has such as the need of transferring large amounts of "money", without tracing, in short times, across the globe but it undoes the benefits that the 99.9% has while bringing complexity. Plus, nobody really wants…

[flagged]

There is a perception that it's magic and untraceable. As you mention, there are obfuscation methods that seem sufficient that criminals have adopted crypto rather than 'Okay, you're gonna have to buy $100k in iTunes cards" to claim their ransomware bounties.

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#52

Post by _nhynes »

hanniabu wrote: post #46
_nhynes wrote: post #42

Earlier quoted context omitted.

With the introduction of CBDCs, FedNow, and platforms like TFA, it's starting to look like TradFi is getting the second-mover advantage. Cryptocurrency introduced programmable money, which is great, but it also came with other features like self-custody, extreme transparency & privacy, and immutability that have ended up being more than average users are willing to accept as a bundle. TradFi entities now have the abi…

You can build features like reversibility on top of Ethereum. A draconian government chain that solves none of the important grievances is not needed. I do not need big brother freezing my funds, deciding what I can and can't buy, etc.

Yes, I completely agree. There's plenty of tech available to achieve many of the goals of functionality, affordability, and privacy a motivated team of developers could have. Just that it's often unnecessarily difficult to build and use. Probably things will be much better in a(nother) decade, but the whole thing is still a work in progress. In the meantime, why pay the cost 100% of the time for avoiding a bad thing that happens 1% of the time? Cryptocurrency has its utility, but much less when minimizing trust isn't a requirement.

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#53

Post by kemotep »

hanniabu wrote: post #50
kemotep wrote: post #49

Earlier quoted context omitted.

Can you specifically describe how Ethereum, where all transactions are public, would prevent this kind of surveillance?

I was referring to the inability of the government to freeze your funds. But there are ways to prevent surveillance using zkproofs where you can break the onchain connection for private transactions.

Putting your eth wallet keys on a “do not transact with” list would be pretty similar. Having to engage in “money laundering” such as those privacy measures you bring up being a reason the government may put an address on the block list would make it quite difficult to get around too.

That is assuming Ethereum sees that kind of mass adoption to the point governments start to regulate its usage.

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#56

Post by matt3210 »

downWidOutaFite wrote: post #25
teamspirit wrote: post #3

Why are these API banks always in the UK? I've been waiting to do my banking using curl for years and no one has made it available in the US.

UK has government mandated API requirements for banks. In the USA it's left to the "free market" which in practice means having to trust unreliable 3rd parties like Yodlee or Plaid.

Lol plaid wanted my username and password for access to my bank for a third party. No way

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#57

Post by seabass-labrax »

teamspirit wrote: post #3

Why are these API banks always in the UK? I've been waiting to do my banking using curl for years and no one has made it available in the US.

After the financial crash of 2008 and the subsequent succession of banking scandals, in which the taxpayer bailed out multiple prominent banks, the UK's government at the time introduced a series of measures to promote smaller banks. For individual personal accounts, Monzo and Starling are probably the most well-known of these so-called 'challenger banks'[1].

[1]: https://en.wikipedia.org/wiki/Challenger_bank

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#59

Post by ilkhan4 »

ilikehurdles wrote: post #23
dataangel wrote: post #21

nothing like having dynamic types manage your money

While I also love to take part in cargo cults, you should probably fit some good blinders on before looking over at Nubank’s stack.

I wish people would stop bringing up Nubank when it comes to Clojure/FP as if it's some sort of mic drop that proves that it's the Right Way to develop financial software. When you have to keep bringing up the same example, it's not a very good argument.

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#60

Post by lmm »

bnert wrote: post #31
dataangel wrote: post #21

nothing like having dynamic types manage your money

In OO languages (Java, C#, C++, etc...), and functional ones (F#, Haskell, OCaml, etc...) types do not validate the correctness of logic, they evaluate the correctness of data structures and their access/mutation as they are manifested in the language. OO languages consider data correctness as access patterns of encapsulated primitives (or other data structures) through defined behaviors on a "class". Functional lang…

> In OO languages (Java, C#, C++, etc...), and functional ones (F#, Haskell, OCaml, etc...) types do not validate the correctness of logic, they evaluate the correctness of data structures and their access/mutation as they are manifested in the language.

Nonsense. Types validate whatever you use them to validate, which can certainly include what we usually call "logic".

> Types have little (or nothing) to do with program correctness

On the contrary, they're still the most effective technique we've found for improving program correctness at low cost.

Post reply on HN