Credit unions as platforms for local nodes?

Yes, I discussed this with (can't remember his name, Gareth X?) the person who set up the Hackney Credit Union. He was receptive to it, but the HCU imploded after less than a year, lots of cash pumped into it, too. But, I believe this 'parallelism' is a good idea. Related, Christian Nold's experiments with RFID tagging of 'existing' currencies: http://www.christiannold.com/archives/1 somewhat 'art' projects but also to do with parallelism.

I recently unsubscribed from that list. I'm not aware of any relationship between credit unions and time banks. I can ask timebanks USA if there was a clear question.

The software used by credit unions in the UK (and everywhere else as far as I know) lacks the flexibility to meet the needs of time banks. Even if the software can be configured to support time accounting (1=1 human hours), the essence of a time bank lies far more in the metadata. However, the word "platform" covers the organizational and legal structure as well, so I agree that credit unions could (possibly with an extension to their model rules, or possibly in partnership with another body) provide time-banking, time-network, LETSystem or broader Open Money services to their members. Since they are savings and loans co-operatives, their services are restricted to their members, but that's not a serious restriction in any way.

Many years ago (around 2013-2015, if I remember correcty) I was involved in a CIC to create a test-driven, agile, FOSS platform for credit unions and CDFIs (CUPRIUM). This originally arose from frustration with the limitations of software used by UK credit unions, it having always been obvious that it was too limited. Similarly, the limitations of Cyclos and other CC-orientated software prompted us to aim for something far more flexible and ambitious. When I outlined the original object model, I allowed for the unlimited addition of new account types with arbitrary properties and functions (including interest, demurrage, delayed leakage, escrow functions, conditional conversions, etc.). One of the many reasons for this flexibility was that it had been obvious for many years that CUs could (and in my opinion should) provide seed- or anchor-points for multiple local economic tools. In some ways I saw this as an extension to the CBP (Community Banking Partnership) model developed by Pat Conaty, Mick Brown, Cliff Rosenthal and others (combining CU, CDFI and advisory services - so limited to LT) in the early to mid 2000s, but I was equally interested in mutual credit, time banks/networks, energy-backed currencies, etc. [Unfortunately we were never able to secure the funding needed to develop this suite (it was conceived as an ecosystem of progressively replaceable modules sitting on top of PostgreSQL, decoupled to the extent practicable), not least because (understandably) CUs generally feel much safer paying a lot of money to make software someone else's problem.]

A couple of years before CUPRIUM (around 2012-2013), I was involved in a project called NEWT (New Energy Wealth Tokens) which started off as an attempt to create an exchange currency backed by locally-generated renewable energy. Unlike "sister projects" such as the Bristol Pound, this was intended for use in a large, sparsely-populated region and had both positive and negative feedback loops built into the design to enable growth to follow need/usefulness, and consequently the design called for greater flexibility than could be met through Cyclos3 without the addition of a number of new classes. (CClite might have been an option, but we were looking to take advantage of the managed Cyclos3 network on which Bristol Pound and others were running.) The NEWT project never got past the feasibility study phase, partly because the local energy scheme around which it would have been anchored never came into being (despite many years of hard work by its developers) and partly because the transition from FOSS Cyclos3 to closed-source Cyclos4 was an unwelcome complication.

Even earlier, I had proposed to my local credit union (Robert Owen Credit Union, of which I was a director from about 2001 to 2013) that it should run time-banking/-network and a LETSystem as standard accounts alongside its LT savings and loans accounts, using a single ID for each member. Just as any bank or building society has a large number of products potentially available to each of their clients - to which attention would be drawn when appropriate - a CU could easily do exactly the same for its members. I had Cyclos3 configured ready to demonstrate for this purpose, but the proposal was considered too ambitious.

(Around that time I created a stub organization, Robert Owen Community Time, although I never reached the point of having to register it as a legal entity. This was a backup plan in case it should prove useful to have a partner organization providing services outside the CU's own restrictions - i.e. as a third party provider for CUs like those providing prepaid cards, current accounts, etc.)

A thread running through all of these was the possibility of creating holonically-nested clusters of tools at different scales (neighbourhood, village, town, county, region, country, continent, planet) for different recusive dimensions (in the VSM sense). For example, at the neighbourhood/village/town level a cluster might include a CU, time-bank, time-network and LETSystem, with any one of these providing an entry point to the extended network which would be largely invisible until useful. Because I visualized this as a collection of islands each populated by a different ecosystm (perhaps a neighbourhood time network being the only option used in one village, a LETSystem and CU being used in a town nearby, and other combinations in neighbouring settlements) with semi-visible connections linking them, I called this the "Archipelago Island Model" (AIM). A couple of years ago realized that the underlying structure I had been looking for was already largely implemented in the Open Money API stack, so that is where I am currently exploring.