Inclusive Finance – Machu Picchu Self-Help Protocol [2]

Photo by Manish Patel on Unsplash

How can proven technologies of the 21st century help the persons-in-need reproduce the ancestral community financial protection practices and improve their life?

Part 1 of this article is here . It explains the context, the challenges and existing solutions. This 2nd part explains the Machu Picchu Self-Help Risk-Sharing protocol and the Go-To-Market.

Machu Picchu Risk-Sharing Protocol

How risk-sharing works in real life

Let's say we are in Vietnam, in the Red River delta, in a village somewhere near Ninh Bình (https://goo.gl/maps/ikuSDJr3w2kHG9J96 ). In this village, Mrs. Nguyên nam Sáu owns and cultivates a small plot of paddy. She and her husband have 5 kids between 4 and 10 years old. She's not rich but manages to spare more or less 1 USD every month. Her ancestral strategy against future hardship is as follows:

• She's part of a village community (circa 30 persons). Rice growing is labor-intensive and requires that everybody participates in communal activities: maintenance of the irrigation waterways, sowing and replanting rice, harvesting and work on the grains etc. Everyone in the community knows each other's "profile" and reputation. Together she and her neighbors have a tacit risk-sharing convention, enforced by the council of elders.
• Mrs. Nguyên nam Sáu maintains month after month some savings. It covers the infrequent needs of the family, whether planned or unplanned. A planned expense could be that her elder son moves to board the secondary school in town. Another unplanned expense could be a replacement of a broken wheelbarrow, or worse, a bad crop season (6 months).
• Normally any planned expense is covered by her savings. Unplanned expense, if small, can also be covered by her savings. If it exceeds her capacity, she calls for help from the others, starting from her relatives, then to her neighbors, then to the council of elders, then she borrows from a local usury or at last resort a bank. The amount of contribution help from her community is usually proportional to her "profile" of past behaviors. The share of contribution required from each other person is made based on their degree of neighborhood with her, see Gospel of Luke, 10:25-37 (https://en.wikipedia.org/wiki/Parable_of_the_Good_Samaritan ).

Mrs. Nguyên nam Sáu reluctantly buys insurance and borrows from banks. Their process is too complicated, too remote from her usual practices, and her network of relationships cannot explain her easily how insurance and banks work. The common understanding is that insurance is wasted money, so she buys insurance only when she borrows in last resort from a bank and the bank requires her to do so.

What challenges are raised to implement risk-sharing?

The challenges are:

• How to put down and enforce a common agreement to share risks? how to agree on a loss? what criteria to use to evaluate compensation of a loss?
• Once the compensation defined, how much should each member of the community participate to the payment? If we use a criterium of neighbourhood, how to objectively define and measure "proximities" of "profiles"?
• Once the share of each participant is defined, how to enforce these rules?

How Machu Picchu enables risk-sharing

The Machu Picchu Peer-to-Peer risk-sharing protocol starts by being focused on crop risk. It is NOT a replacement to traditional insurance.

The overall principle of this risk-sharing protocol is that each participant saves money at their own pace in a smart contract that is called the RS Pool. This money remains under control of each person, meaning that this person can withdraw any part the money from his own RS Pool, under some conditions.

The protocol withdrawal described below is still in progress. It is inspired closely by the ancestral practices in most rural communities.

• If the withdrawal is done only at the initiative of the owner, for her own need without any justification, it is executed within the limits of the contents of the RS Pool of this person. A certain percentage of the withdrawal (20%) is retained as penalty. Of them, 18% are transferred to a common RS pool and 2% serve as reward to the author of the risk-sharing smart contract (RS Pool of this person).

For example, the owner may want to use this saving to buy a bicycle to her son to go daily to the town school, instead of paying a boarding house. It is unrelated to her crop risk.

• If the owner justifies the withdrawal request by declaring being victim of a risk, this occurrence is assessed by a vote of the community of members. If the vote is positive, the withdrawal is done without penalty and furthermore if the owner's RS Pool is not large enough, each member of the community contributes to part of the payment from his own RS Pool.

For example, the owner may want to declare a loss that is smaller than her savings in the RS Pool. If this is confirmed by the community, the amount with be taken only from the RS Pool of this person. If the declared and accepted lost is larger and exceeds the capacity of the person, then the rest of the community will contribute to cover the loss up to the amount required. This is risk sharing in action.

Because each of the voters participate in the risk compensation from their own RS Pool money, this reduces the risk of complaisant voting. The information asymmetry when there is a third-party insurer is inexistant: the community has the same information as the loss victim. There is no third-party insurer to cheat.

• The total of the community compensation is a combination of the merit of the person and of the frequency of the risk. Concretely, it is calculated from the average monthly amount saved by the victim for risk sharing, times the average number of months between occurrences of such the severe loss as claimed in the withdrawal request.

For example, if the claim would be for a loss that happens once every 5 years, and if the victim's average monthly savings to her own RS Pool is 1 USD a month, then the community would help to withdraw 1 x 12 x 5 = 60 USD.

The withdrawals that are done for personal purposes are discounted from the average savings effort of a person. But the withdrawals justified by confirmed loss by the community are not discounted.

• The contribution of other members sharing the risk with the victim is calculated using the proximity distance of the "vector" describing each member. Each personal contribution is capped by the person's individual RS Pool.

The "vector" is an outcome of recent AI technology, see explanation here: https://chat.openai.com/share/a4f633d2-e736-4f7b-a8ee-44c990705480 . It may contain a family name, a geographical location of the plot of field, nature of the crop, crop season and other factors. See a tutorial here: https://towardsdatascience.com/encoding-data-with-transformers-d14445e96ead .

• If all other members suffer the same loss and their cumulated RS Pools cannot cover the totality of losses, the additional amount is taken from the community RS Pool that stores the penalties of unrelated withdrawal.

This should be exceptional when the size of the Machu Picchu community is large enough. But it can happen is case of regional of national catastrophes. In such a-case, the government will certainly take also solidarity measures.

Machu Picchu Go-To-Market Approach: Build Profile Sharing Community

The Machu Picchu Go To Market must solve a double egg-and-chicken challenge:

• members will participate only if the size of the risk-sharing community is large, while this community can exist only if there are enough participants.
• the infrastructure is worth being built only to support to a large community, while a community can be built and grow only if the infrastructure exists.

To bootstrap the infrastructure and the community, there is an immediate solvable need that can be addressed by Machu Picchu. The need is that today, the International Helper Organisations are crying for quality data about the persons-in-need.

The pain when collecting and maintaining data

• International Helper Organisations need quality data to build their aid programs and to justify the use of fundings to donors.
• International Helper Organisations rely on field helper associations to collect this data. In exchange, they fund these associations, based on local projects that match the international programs.
• However, the field helper associations are more interested in day-to-day support of the persons-in-need than to collect, validate, format the data to suit the International Helper Organisations.
• The data is defined and collected in a very old-fashioned way, using methodologies and practices of the 70's, more than 50 years ago. Nobody uses new technologies that the GAFA (Twitter, Facebook, LinkedIn, Google etc.) deploy to maintain the profiles of their users.

As a result, the farther the data travels from the source, the more degraded their quality become.

In Machu Picchu each person-in-need maintains and sells their data

In Machu Picchu, because each person-in-need maintains their own profile for use in defining a risk-sharing neighbourhood, these profiles can be made available to International Helper Organisations.

• Each person-in-need, together with a few helper persons that already constitute the backbone of a community, form together an "abstract account" in the sense of Ethereum ERC 4337 (see explanation here ). They communicate between them only using SMS or USSD. The person-in-need knows nothing about blockchain.
• Together, this "abstract account" regularly updates the profile of the person in need. A summary is posted in IPFS for free access by Helper Organizations and by any interested institutions.
• Any Helper Organisations, be it a governmental agency, an international organisation, a commercial input provider, an international agro-industry (for example Nestlé, Mars) etc., can retrieve data from IPFS. From this data, these organizations can query the different smart contracts that are associated with the tokens owned by the person-in-need. But to retrieve further they need to pay the smart contract to obtain the information.
• The payments are done to the "wallets" (in the sense of ERC 4337) of the abstract account.

ERC 4337 defines as a "wallet" a smart contract that represents the blockchain "avatar" of a user for a specific service. We can consider such "wallet" as a very sophisticated credit card. It would know its balance amount, what payments can be done with it, in which currencies, under which conditions, to which beneficiaries, and execute actions it is programmed to do in each transaction.

In our Machu Picchu example, a "wallet" for profile publishing of a person would know how to retrieve each component of the profile of its owner). It would accept a query on this profile, would validate that the query price has been paid to an escrow and receive the payment from the escrow. It can also apply a different query pricing depending on the query originator and the freshness of the data etc.

Such "wallet" is totally GDPR-compliant because the "data controller " is also the "data processor ".

Benefits of profile sharing

The way this profile sharing is maintained and sold benefits to every stakeholder:

• High quality, up-to-date data. The data owner is the person-in-need maintaining their own profile. Pricing the data access can be defined by each owner, or by a common smart contract protocol based on data freshness, on nature of the querying body and other factors to be defined, or finally by a "wallet" smart contract specifically defined by each organization, as defined by ERC 4337.
• No proprietary data scheme. The data is in ordinary language, local to each country. It will be transformed by each organization into vectors by AI word embedding applications.
• The field helper staff is relieved of the boring task of checking and maintaining "Excel tables". Profile updating is done by periodically launching an appropriate mobile app.

Profile-sharing challenges and technical solutions

All technologies to help the person-in-need are available, at low cost.

• Mobile apps, used by field helpers ("field sponsors") to help the persons-in-need use blockchain transactions to update their data and collect their fees
• Mobile SMS messaging, used by persons-in-need to contribute and update their data with the help of the above
• Ethereum Account Abstraction (ERC 4337) to simplify blockchain usage. One abstract account is no more a cryptographic key but a community of persons who may use basic cellular phones combined with smartphones
• Low cost-low power servers like Raspberry Pi SBCs to act as blockchain nodes and distributed storage nodes

The technologies to take advantage of the profiles are more expensive but affordable to the Helper Organisations. Eventually Machu Picchu may provide consulting services to build these tools.

• Blockchain explorers
• Digital Currencies and Tokens
• Text encoding into vectors using IA tools
• Vector databases to analyse data more efficiently