[HN Gopher] Griffin - A fully-regulated, API-driven bank, with C...
___________________________________________________________________
Griffin - A fully-regulated, API-driven bank, with Clojure
Author : coder94
Score : 156 points
Date : 2023-08-29 20:06 UTC (2 hours ago)
(HTM) web link (www.juxt.pro)
(TXT) w3m dump (www.juxt.pro)
| jsyolo wrote:
| They tried really hard to not use a distributed SQL database.
| venantius wrote:
| Because it's not a great fit for an event driven architecture.
| xyst wrote:
| Despite the unpopularity here. I am still a fan of cryptocurrency
| as an alternative to traditional banking.
| jokoon wrote:
| Unless finance institutions and laws can protect wallets and
| insure crypto, I will never use it. Currency is not just a
| number you move around, currency is deeply intertwined with how
| civilization works, and it requires a high amount of trust for
| people to use it.
|
| Trust is rather a social concept that something you can really
| prove mathematically. It's collective trust. Unless you can
| DRASTICALLY reduce mis-use with bitcoin, no one with trust it
| ever without a lot of expensive protective measures.
|
| A 1 hour lecture from a security professor on crypto currency:
|
| https://www.youtube.com/watch?v=J9nv0Ol-R5Q
|
| Something else:
|
| https://www.youtube.com/watch?v=0AAUrMuMPlo
| dsco wrote:
| Cryptocurrency is also even better than Clojure at being
| auditable as everything is on-chain all the time.
| _nhynes wrote:
| 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 ability to pick what they like out
| of the mix and offer that to customers while also benefiting
| from the convenience of trust assumptions, something
| cryptocurrency eschews. TradFi is building atop thousands of
| years worth of UX improvements in how people can come to trust
| each other. It's difficult for cryptocurrency to compete there.
|
| I still love the developer convenience of blockchain since it
| nicely combines serverless with auth with payments. But for the
| most part, given the existence of trust, these benefits could
| also come from a system like in TFA having a Wasm runtime and
| maybe a dash of WebAuthn. Like a mashup of Cloudflare Workers
| and Stripe.
| hanniabu wrote:
| 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.
| _nhynes wrote:
| 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.
| epolanski wrote:
| 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 a deflationary currency, they don't
| work, the incentive is to hoard and hold, not spend, which is
| why even Bitcoin's website dropped the currency narrative for
| the store of value.
|
| People don't buy Bitcoin to trade or pay, but to sell at a
| higher price. Exception being drug dealers and few lunatic
| anarcho-capitalists.
| siftrics wrote:
| [flagged]
| hakfoo wrote:
| 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.
| howmayiannoyyou wrote:
| Its not clear there will be small banks in the US to use this
| tech in the future. Here's why:
|
| 1. Deposit flight. Small banks are struggling to attract deposits
| at a time when money markets pay considerably more than deposit
| accounts.
|
| 2. Investment scarcity. Small banks are struggling to find places
| invest deposits where returns are safe, on a reporting adjusted
| basis. Meaning, small banks invest(ed) in US Treasuries, but as
| the Fed has rapidly hiked rates, the mark-to-market value of
| these investments has declined (though the funds are safe). The
| same can be said of new lending, which has similar problems due
| to credit risk, primarily in commercial real-estate.
|
| 3. Perceived risk. Rather than allow depositors to purchase
| additional FDIC insurance (above the $250k limit), which
| insurance would generate revenue for the FDIC and banks, the
| USGOV had done nothing. If you want to insurance excess deposits
| you must use an IntraFI account that spread deposits among
| different banks, and/or brokered CD's which does the same for
| that banking product. Both are higher friction, and both prevent
| instant access to funds - regardless of one's tolerance for
| penalties.
|
| 4. FISERV missteps. Small banks rely on Fiserv and a few other
| vendors to for back office and retail banking systems. In
| Fiserv's case their software is well behind big bank products
| that provide more features and easier user interfaces. Younger
| banking customers prefer big bank systems.
|
| 5. Regulatory overreach. Complex issue, but in sum its not clear
| bank regulators understand the banking business, or if they do,
| that they have any flexibility. By way of a few examples, its not
| clear to me regulators understand the safety & utility of
| brokered deposit use by small banks; the worthlessness of many
| bank capital asset appraisals, or the immense risk real-estate
| heavy loan portfolios are facing.
|
| 6. Asset-based lending death. Pre-2008 one could borrow against
| many types of capital assets, allowing businesses to purchase
| those assets with, say, 20% down. The asset secured the loan,
| with little or no reliance on personal guarantees or recent cash
| flow analysis. This practice led to problems in the 2008 GFC, but
| instead of tweaking the approach, lenders and regulators simply
| eliminated asset-based lending. When I write 'eliminated' I fully
| understand its still advertised as a lending product, but
| underwriting is reliant on cash flow, personal financial
| statements, and other factors that make 'asset based lending' a
| marketing term, not reality. This was profitable business for
| banks and didn't need to die.
|
| More threats lie ahead for small banks in the US. Folks in the
| know speculate USGOV prefers the Canadian model, where most
| deposits are held by several big banks. It might be the case
| FedCoin opens new possibilities for small banks, reducing Fiserv
| and friends hold on small banking business. One can always hope.
| Lyngbakr wrote:
| James Trunk, who is now Griffin's VP of Engineering, gave one of
| the most clear and enjoyable technical introductions to Clojure
| I've seen. Recommended!
|
| https://youtu.be/C-kF25fWTO8?si=PnjMNLdBLJ8zqSu-
| gremlinsinc wrote:
| I absolutely hate when an articles starts out with:
|
| > IN A STARTUP, YOU SHOULD BE USING THE MOST POWERFUL LANGUAGE
| YOU CAN, AND THAT IS CLOJURE.
|
| says you. one opinion. in a startup you should use the language
| that your team can build and launch your MVP the fastest so you
| can get your first customers or funding. Hell, this could be a
| low code or no-code platform(probably not in fintech, just saying
| with startups in general).
|
| I mean, I'd say Python is the most powerful language because of
| LLMs and machine learning and generally I'm a PHP dev. Python
| also is about to get a ton more powerful with mojo which
| supposedly makes Python 36000x more performant.
|
| However, I would never tell someone x is the most powerful
| language and only one to use for a startup because that's a total
| lie and opinion.
| renewiltord wrote:
| I see. So this helps you build a Neobank or something like that.
| It's Mambu for the UK?
| dataangel wrote:
| nothing like having dynamic types manage your money
| ilikehurdles wrote:
| 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.
| bnert wrote:
| 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 languages consider data correctness as access
| patterns which preserve previous version of data which a caller
| may still need to reference, or another part of the system
| references. Functional languages (in most cases) disallow
| direct mutation without some sort of immutability or
| persistence.
|
| Types have little (or nothing) to do with program correctness,
| or data correctness as it relates to external storage engines
| and their concurrency guarantees (i.e. FoundationDB,
| PostgreSQL, MySQL, etc...).
|
| Therefore, in this scenario, what matter's most is the
| correctness of underlying storage (including the rigor of
| validating expected behavior) and the event sourcing/messaging
| systems, not on the internal data structures and their idioms
| conveyed by the language.
| Animats wrote:
| Well, not yet. "The training wheels come off when we complete an
| audit, raise some more money, and finish writing the code. That
| should be Q3 or Q4 this year."
| davewritescode wrote:
| How does this compare with SoFi's Galileo platform just in terms
| of feature set. The Galileo API is fairly rich so I'm wondering
| what's different and potentially better.
| fuddle wrote:
| It's pretty cool to see that the two founders wrote a book
| together: "Learning ClojureScript"
| https://www.packtpub.com/product/learning-clojurescript/9781...
| teamspirit wrote:
| 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.
| orra wrote:
| > Why are these API banks always in the UK?
|
| I can think of 835 million reasons:
| https://www.reuters.com/article/eu-rbs-britain/corrected-uk-...
|
| Plus, Open Banking and Faster Payments (which were EU
| initiatives before Brexit) maybe helped.
| blibble wrote:
| faster payments had nothing to do with the EU
|
| "open" banking did (and accordingly you have to be a large
| company to participate at all)
| avianlyric wrote:
| U.S. banking is surprisingly far behind the curve, and hasn't
| led the world from a tech or innovation perspective for many
| decades.
|
| The UK on the other hand has actively encouraged new banks and
| new tech. It's had things like instant, free, payments between
| personal accounts for almost two decades. Contactless
| transactions for at least a decade, mobile banking for decades,
| and government mandated banking API for almost 5 years.
|
| In short, the UK has a very active banking sector that's been
| rapidly (for banks) innovating for many decades. So the
| environment and ecosystem are well developed for further and
| faster innovation.
|
| In the U.S., it seems banks gave up on tech innovation decades
| ago, and decided that innovation in fees and punitive treatment
| of customers was their preferred approach. As a result there
| just isn't an environment for new innovation, the incumbents
| find it much easier to crush competition, rather than compete.
| Why the same isn't true in UK (which until recently had
| remarkably few distinct banks), is probably down to the nature
| of law and regulation, which gives customers lots of rights,
| and actively punishes banks that don't uphold them.
| edent wrote:
| In part because of the "Regulatory Sandbox" -
| https://www.fca.org.uk/firms/innovation/regulatory-sandbox
| venantius wrote:
| Actually, no - the regulatory sandbox cannot be used by
| prospective banks.
| vermilingua wrote:
| Does anyone know why this is the case in Australia too? Is
| there a regulatory reason or is it just a matter of market
| size?
| downWidOutaFite wrote:
| 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.
| matt3210 wrote:
| Lol plaid wanted my username and password for access to my
| bank for a third party. No way
| tazjin wrote:
| It's fairly common in Russia, too. Mostly because some
| "challenger banks" forced everyone else to modernise.
| matt3210 wrote:
| Yes! I need an api bank for personal use too!!
| ctdean wrote:
| Getting a new banking charter in the US is hard, but it's
| straightforward to be a challenger bank in the UK. Jarvis moved
| (back) to London from SF to start Griffin.
|
| The banks in the US that have APIs tend to focus on large
| fintech partnerships, so even simple APIs will be expensive
| compared to a regular bank account. Grasshopper Bank in the US
| (for example) is one of the few that will do APIs on top of
| regular commercial bank accounts.
|
| (I work at Treasury Prime, which powers many US banks that do
| APIs.)
| venantius wrote:
| It's hard in the UK too! Just not "infeasible" hard. (Plus,
| it's easier to finance as you don't have those pesky Bank
| Holding Company Act regs dinging your investors)
| mfreeman451 wrote:
| [dead]
| vichle wrote:
| Maybe I'm missing something, but it sounds like there's a strong
| case for Erlang/Elixir rather than Clojure? They kinda built BEAM
| on the JVM, no?
| matt3210 wrote:
| For businesses only it seems. I'd love a bank for personal use
| that was API accessible...
| yuumei wrote:
| Unfortunately in the UK a bank can (and do) freeze your account
| with no reason for up to 2 years without any recourse or access
| to funds. With API access you risk your money being frozen due to
| automatic fraud detection. The government have given up policing
| of finance to banks and they take the least risky options
| venantius wrote:
| I wouldn't say "given up" as much as "actively delegated".
|
| The UK has essentially made a (political) choice that rather
| than cover the cost of policing finance through taxes, they'll
| just make the banks sort it out for them.
|
| This is not great for some people for obvious reasons. But for
| everyone else it's lower taxes. Where one falls on the
| political spectrum largely determines how one feels about this.
| CTDOCodebases wrote:
| It's part of the privatisation of the surveillance state.
|
| Money isn't the only motivation factor.
| hanniabu wrote:
| Yet another example for why Ethereum is needed
| kemotep wrote:
| Can you specifically describe how Ethereum, where all
| transactions are public, would prevent this kind of
| surveillance?
| hanniabu wrote:
| 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.
| kemotep wrote:
| 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.
| fabianhjr wrote:
| And in the US they got civil forfiture:
| https://en.wikipedia.org/wiki/Civil_forfeiture_in_the_United...
|
| > To get back the seized property, owners must prove it was not
| involved in criminal activity.
|
| Some cases:
|
| https://ij.org/report/policing-for-profit-2/grading-state-fe...
|
| https://prosperityeconomics.org/stolen-savings-civil-forfeit...
| dataangel wrote:
| > In 2015, Eric Holder ended the policy of "adoptive
| forfeiture", which occurred "when a state or local law
| enforcement agency seizes property pursuant to state law and
| requests that a federal agency take the seized asset and
| forfeit it under federal law" due to abuse.[21] Although
| states proceeded to curtail the powers of police to seize
| assets, actions by the Justice Department in July 2017 have
| sought to reinstate police seizure powers that simultaneously
| raise funding for federal agencies and local law
| enforcement.[22]
|
| basically Obama got rid of it then Trump put it back then
| Biden didn't anything
| downWidOutaFite wrote:
| Your first link says the IRS stopped doing forfeiture of bank
| accounts 9 years ago.
| varispeed wrote:
| These "challenger" banks are a gimmick. Friend of mine recently
| tried to set up an account for his new business and all
| "challengers" refused a business account, they were slow to
| respond and disinterested in helping. Eventually he set up with
| a high street bank, but the whole thing took over a month,
| which is ridiculous.
| monooso wrote:
| My experience of banking with both Starling and Monzo
| (personal and business) has been excellent. Far better than
| with any of the high street banks.
| toyg wrote:
| That's surprising. Starling opened a business account for me
| in less than 3 days. This was back in 2018 though.
| oldtownroad wrote:
| "By law, fintechs must work with a bank to do these things, and
| right now that means a legacy high street bank with mainframes.
| Griffin is the bank plus technology platform that all future
| fintechs would build on."
|
| Did they write this in 2016? The market has moved on. Griffin
| looks neat but they're years behind many others, a nice API for
| banking exists from well established players, like ClearBank.
| There's room for more so it's great to see Griffin join the
| market but I hope their pitch isn't this weak.
| varispeed wrote:
| > that all future fintechs would build on
|
| This also sounds awfully like a single point of failure and
| embodiment of what's wrong with late stage capitalism - where
| competition is an illusion.
| venantius wrote:
| There still isn't a ton of choice in market - ClearBank is one
| of three other banks that actually have decent offerings. And
| having a good API is not enough; you need a holistic operating
| model that is aligned with your customer base, which is much
| harder to build for.
| nathell wrote:
| > and this additional proprietary thing that I really need to
| open source (I ported Datascript to FoundationDB).
|
| Yes please! I wonder how that plays out as an alternative to
| Datomic.
| gremlinsinc wrote:
| the whole article read to me like a guide: How to over engineer
| a project for kicks and giggles.
___________________________________________________________________
(page generated 2023-08-29 23:00 UTC)