[WKT] MIP6 MCD Application: WizKey Token - Insured tokenized invoices

MIP6 Application: WizKey Token WKT: Insured tokenized invoices

This is the MIP6 proposal for the addition of WizKey’s tokenized invoices insured by one of the three main credits insurance company in the world, rated AA- by Fitch and A2 by Moody’s.

WizKey aims to provide its customer enterprises with a new source of financing allowing them to use their invoices as collateral in MCD, therefore it is making its application with the MakerDAO community. Furthermore, we want to bring real-world assets into the MakerDAO ecosystem, strengthening use cases of the protocol. As currently envisioned, our collateral is substantially risks-free for the Maker Foundation and the protocol itself, granting no liabilities as the exposure is to the insurance company and not the issuer itself, namely the companies. WizKey has the obligation of repaying the debt position opened with MakerDAO and, should the invoice not being repaid, the position will be covered by the insurance reimbursement.

We envision this as a great opportunity of growth for the MakerDAO ecosystem, onboarding one of the most important real-world assets. At first, we aim to conduct a pilot operation here in Italy, where the total addressable market is more than $ 2 Trillion. Usually the total value of the issued invoices in a country is a bit more the GDP, so the worldwide addressable market is huge: even a minuscule percentage of that means massive volume for the ecosystem.

Nevertheless, we want to be sure that the interest rates on this kind of collateral is proportionate accordingly to its risk and to the rating of the insurance company. At the time of writing, the interest rates applied to bonds assigned with an AA- rating is largely negative (-0,5% for 1 year maturity), making possible to provide low interest rates. As an example, Credimi, an Italian fintech company providing factoring and invoice discounting through traditional centralized systems, for the same kind of operation we want to put in place, applies an interest between 4-7%. So, if an interest of, let’s said, 2% is applied, it could be very competitive and gains a lot of traction.

After this short intro, please find hereinbelow our answers to the community, hoping that they will be warmly received.

1. Who is the interested party for this collateral application?

WizKey s.p.a. is an Italian fintech company founded by Marco Pagani (the main contact for this application) and Roberto Ghio, two lawyers with 40+ years’ experience in finance law and structured finance operations, with a deep understanding of the blockchain technology.

Wizkey has deployed Define, a decentralized market for tokenized loans, invoices and asset backed securities. Define is a trustless and end-to-end platform that gathers and certifies all the information related to loans and invoices in order to ensure the buyer with transparency and certainty about the purchased receivables. WizKey Define grants compliance and privacy by design, allowing users align with regulation while preserving high confidentiality in every transaction.

2. Provide a brief high-level overview of the project, with a focus on the applying collateral token.

We provide, first, a brief overview of the collateral we want to use, then, the proposed integration within the MakerDAO ecosystem to use tokenized invoices as collateral for MCD.

Here’s the brief overview of the asset proposed to be used as collateral:

  • Collateral: Invoices issued by SMEs guaranteed by a AA- rating insurance company
  • Days Outstanding: 90 days invoices
  • Collateral Coverage Ratio: 100%
  • Interest Rate to Borrowers: 4-7%
  • Type of Advance: Factoring

As stated in the introduction, the addressable market is huge, even in minuscule percentages. The Italian market, for example, was worth more than $2 trillion in 2019 meaning that if we manage to route 1% of it on MakerDAO, the volume generated will be billions of dollars per year. Furthermore, by its own nature, the collateral proposed suffers extremely low volatility, further lowered by the insurance applied.

Here is the workflow for the proposed collateral, with an example of $100 invoice and 4% annual interest rate (i.e. 1% on 90 days):

# Activity Days
1 The company (Customer) upload the business profile and financial statement on WizKey; 1
2 The insurance company approves the customer and notifies WizKey that it accepts an exposition of up to $100; 3
3 Customer and WizKey enter into a token trade contract for: 100 DAI worth $1 each and a price of $101 to be paid in 90 days; 4
4 WizKey issues a $101 invoice to 90 days to the Customer (Invoice) and insures it with the insurance company; 4
5 WizKey uses the invoice as collateral in a smart contract that issues 100 DAI (Debt Smart Contracts); 4
6 The Customer exchanges 100 DAI for $100 on an authorized platform; 4
7 The Platform pays $100 to the Customer through a wire transfer; 5-6
8 The Customer repays $101 to WizKey in 90 days; 94
9 WizKey purchases 101 DAI on the market; 95
10 WizKey sends 101 DAI to the Debt Smart Contract to close it. 95

3. Provide a brief history of the project.

WizKey was incorporated in August 2018 and developed its first working PoC for the tokenisations of banking loans and invoices, privately released in April 2019, and is being currently commercialised after a one year fine tuning with several banks and servicers. We’re working with several financial institutions in Italy and negotiating two big joint ventures with primary standing players.
Our platform DeFiNe has been awarded with the Seal of Excellence in the context of the European Union “Horizon 2020” programme.

Define is a peer-to-peer and trustless solution in which every user has absolute control and ownership on its own data that is then double checked with public databases.

The three main components of WizKey Define are: Wizkey Client (WKC), WizKey Node (WKN) and WizKey Services (WKS).


WizKey Client (WKC) is a standalone application on the customer device that joins on-chain and off-chain operations.


  • Uploads documents to WizKey Node and creates data rooms and portfolios.
  • Directly requests notarization and tokenization to the blockchain, computing the hash value for each document, then sharing metadata with the corresponding WizKey Node:
  • Exchanges data with a WizKey Node to which it is authorized


WKC guarantees no intermediation: the owner of the WKC signs every operation, with no service in the middle.

WKC document hashing ensures that proof-of-existence cannot be compromised, receipts that contain hashes are stored safely, and documents content cannot be reversed, thus protecting privacy.


WizKey Node (WKN) is a docker image deployable on a containerized infrastructure both on premise and on a dedicated cloud account.


  • Stores documents and offers document metadata creation and storage, as well as AI services that are directly deployed to analyze documents
  • Provides audit on blockchain receipts, embedding an Ethereum Node


WKN enforces privacy since sensitive contents never leave customer domain and no data is shared with WizKey at any time.

WKN verifies content notarized by clients, ensuring documents and transactions integrity.


WizKey Services (WKS) are a single tenant cloud hosted services released by WizKey on AWS that implement routing and login services.


  • Authenticate users ensuring Know Your Customer (KYC) across different data rooms

Provide WizKey Node address book when needed to fulfill settlement operations.

The platform Define has not been publicly released yet, but it is being used for few pilot operations with big Italian banks. The first one should be concluded by the first half of June 2020.

4. Link the whitepaper, documentation portals, and source code for the system(s) that interact with the proposed collateral, and all relevant Ethereum addresses. If the system is complex, schematic(s) are especially appreciated.

We can host an online presentation of our platform for the community, that will be likely hosted on Zoom or similar apps; we can’t wait to show you our platform to receive comments and reviews in the context of this application.

Please refer to the section above for a quick overview of the platform.

We haven’t released a whitepaper nor the code has been publicly made available. As we’re a private company backed by private investors, we decided to go this way in accordance with their requests and to protect their investment for the initial phase. Once the platform will be publicly released, everything will be disclosed.

Here are the links to the smart contracts we deployed on Mainnet:

Notarization: https://etherscan.io/address/0x9b9a2f64cd48c20a884eec0372c9793247258279

Token: https://etherscan.io/address/0xcA2b39DE304221a6CD76f79fEF2368cF69ba7DEb

5. Link any available audits of the project. Both procedural and smart contract focused audits.

There are no audits available at the moment but take a look at the smart contract deployed referring to the links above.

In any case the project has been validated by the financial institutions we are working with, regulators and Horizon 2020 programme.

6. Link to any active communities relating to your project.

WizKey is part of the Italian Fintech district, a network of fintech companies based in Milan.

We’re also part of the Enterprise Ethereum Alliance and one of the initial testers of their testnet.

Here you can find the links to our social:

LinkedIn: https://www.linkedin.com/company/thewizkeysolution/about/

Twitter: https://twitter.com/WizKeySolution

7. How is the applying collateral type currently used?

The collateral is used in the context of factoring programmes as well as securitisation programmes.

8. Does one organization bear legal responsibility for the collateral? What jurisdiction does that organization reside in?

WizKey is the linking point between the companies being financed and Maker DAO and is responsible for the repayment of the collateralised debt positions. WizKey ensures Maker DAO that the final beneficiary of the loan, the Client / company, is obliged to repay the loan and that this obligation is covered by a AA insurance policy, that can then transferred to Makerd DAO fundation in case of any event adversely affecting WizKey. WizKey and the companies that will take part to the experimentation reside in Italy.

9. Where does exchange for the asset occur?

The exchange of the asset usually occurs in Italy through specific operations on the primary market, but there are some international commercial papers programmes available as well.

10. (Optional) Has your project obtained any legal opinions or memoranda regarding the regulatory standing of the token or an explanation of the same from the perspective of any jurisdiction? If so, those materials should be provided for community review.

Securitisation and factoring programmes are widely recognised and used in Italy. We have presented the project to Bank of Italy in September 2019 and made a new presentation in April 2020 and received a very good feedback. The banks and servicers that are working with us do not see any legal problem with respect to the tokenisation of loans and invoices on Ethereum. Furthermore the overall legal design of the platform has been conceived by two very well recognised lawyers that are the CEO and President of the BoD of WizKey.

11. (Optional) Describe whether there are any regulatory registrations for the token and provide related documentation (including an explanation of any past or existing interactions with any regulatory authorities, regardless of jurisdiction), if applicable.

No regulatory registrations are required

12. (Optional) List any possible oracle data sources for the proposed Collateral type.

DeFiNe is the oracle for the collateral. DeFiNe gathers all the data from the debtor and double checks it from public sources.

13. (Optional) List any parties interested in taking part in liquidations for the proposed Collateral type

We are contacting different factors in order to be the buyers of last instance of the invoice should the company fail to repay the loan from Maker DAO. The debt is in any case covered by the AA insurance policy.


Hi everyone, I’m Marco Pagani the CEO of WizKey.

We created a platform for the management and transfer of receivables (bank loans and invoices – the transfer of such assets from a legal and technological standpoint is very similar) in order to provide liquidity to banks and enterprises on the primary and secondary markets. The platform – DeFiNe – allows users to tokenize their receivables, link them to the underlying documentation, pool them and issue securities following the asset pooling. The platform is designed both for the transfer of large receivables portfolios and both for single names receivables transfers (i.e. receivables linked to a single debtor).

Following the 2008 financial crisis in Italy and Europe there was a struggle for liquidity on the SMEs side and a burdensome ratio of non-performing-loans in banks’ balance sheets; following the Covid-19 crisis the situation looks even more grim. On the other side this may be the perfect storm on fiat economy that will allow decentralised organisation to show to the world why we need new structures and new business models to sustain the real economy.

I designed DeFiNe based on my experience in structured finance (factoring programmes, loans securitisation and project financing for green energy) and M&A transaction (mainly in the renewables energy sector), and thanks to the effort of the team we are now deploying our solution in different Italian banks as well as in some enterprises (for factoring purposes).

In the original blueprint of DeFiNe Maker DAO was already incorporated, as I think that on the one side companies need new sources of liquidity for their working capital needs, as factoring programmes are not enough, and on the other side I really think decentralised finance is here to stay and needs the onboarding of real economy to rocket jump in volumes and become a stable player in the global economy landscape. As you red in Jack’s application in fact we want to use companies invoices, granted by a AA- insurance policy, as collateral for Maker DAO.

I’m here to know what the community of Maker thinks about our platform, if there’s something on our project that you’re willing to know and if you need to have some part explained in more detail. Structured finance is a complex field, so if you have any question please don’t hesitate and ask: I’m here with Jack to answer all of you. We are deploying an industrial grade project and we’re eager to involve the Maker community in it.

Hope to have the greenlight by your teams to start working on this asap!



Maybe I’ll get the ball rolling. Forgive me if this is an insensitive question given the possibility of competition. I’ve just recently got my head around centrifuge and the tinlake contracts and how they deal with what sounds like a similar problem. Could you maybe speak to how the wizkey solution differs operationally, and in terms of scope?

I guess I have some other questions too:

  • How does the behaviour described above interact with WKT (the token)?
  • What are the major risks that you see to MakerDAO that could come from onboarding WKT?
  • What benefit does WizKey get from MakerDAO onboarding WKT?
  • Are there any ‘special’ considerations MakerDAO would have to take into account when modifying risk parameters for the WKT token?



Hi LongforWisdom,

Thanks for your time and your questions; please find hereinbelow our answers

(1) Maybe I’ll get the ball rolling. Forgive me if this is an insensitive question given the possibility of competition. I’ve just recently got my head around centrifuge and the tinlake contracts and how they deal with what sounds like a similar problem. Could you maybe speak to how the wizkey solution differs operationally, and in terms of scope?

We’re well aware of centrifuge and the tinlake contracts and we support them. Anyway, we don’t think we’re in competition as they’re really focused on freight and music streaming invoices while our primary target is to provide a solution to Italian and European small and medium enterprises (SMEs) working capital problems; in particular our network is of industrial Italian SMEs based in north / north east Italy. The general business problem we want to solve solve is the same semantic / business area but the target enterprises are quite different; moreover, as you see in our proposal, our system, at least in phase 1, is more similar to a loan secured with invoices than outright invoice financing (this in order to provide, at least in phase 1, more control in the process with the intervention of WizKey and the insurance company). We also think that the way our system is designed, is more straight-forward than the solution proposed by Centrifuge, not worse or better, but just simpler as we understood it. We don’t intend to be in competition with Centrifuge at all, as I said before, because they have a specific focus while our primary target is different. The invoices’ market is huge, it’s probably better to have different projects on different segments of the market so we and Centrifuge are potential partners more than competitors.

The main plus we have compared to Centrifuge is the insurance applied to all the invoices tokenized and used as collateral in the MCD. This makes the system very stable and substantially risks-free, as the exposure is on the insurance company we work with that is rated AA- just like American treasury bond (i.e. Maker DAO would have to discount the same risk as US treasury bonds). Another operational difference is how we onboard and tokenize invoices: there is an automated double-check between the CRM used by the company and the Italian Tax Authority (Agenzia delle Entrate) to ensure that it exists and the amount displayed is correct.

Anyway, I’ll answer to your questions one-by-one hereinbelow.

I guess I have some other questions too:

(2) How does the behaviour described above interact with WKT (the token)?

The WKT is an ERC-721 issued when an invoice is uploaded on our platform. Once created, the WKT is sent to the MCD for the loan and then, once the MCD is closed, the WKT is burned.

(3) What are the major risks that you see to MakerDAO that could come from onboarding WKT?

As I said, we don’t see major risks coming from the onboarding of the WKT, as all the onboarded invoices are previously double checked with the Italian Tax Authority and then insured by one of three main invoices’ insurance in the world. From the regulatory side, we discussed the project with Banca d’Italia (the Italian regulator on finance activities) and it was well received with no particular remarks. We’ll probably apply for the regulatory sandbox activated in Italy for innovative financial projects.

(4) What benefit does WizKey get from MakerDAO onboarding WKT?

We envision benefits for both sides. By our side, we’re pleased to have an introduction in the Ethereum community proposing a project that we’re thinking on in the last 2 years at least. Moreover, we could widen the user base of our platform and open it to SMEs, providing them a useful tool to access liquidity: we really want to provide support to our economy and to our generation. Economy has been stagnant in the last decade here in Italy following the 2008 financial crisis, and now that we have the right tool to intervene and support companies (and therefore workers) we shall act with speed and decision, before the Covid recession unfolds.

(5) Are there any ‘special’ considerations MakerDAO would have to take into account when modifying risk parameters for the WKT token?


I think that it should take into account three main elements: (i) that all the invoices are insured; (ii) that all the counterparty risk is on the insurance company (AA.) and (iii) the average discounting that factoring companies propose for insured invoices in order to be competitive in the market (we envisage a low interest rate and a really high volume).

As stated in the application, we would be very happy to organize a public presentation of the platform for the MakerDAO community, it could be very useful for everyone to see what we’re talking about.

Thanks again for your questions, I hope to have cleared your doubts.




Marco, I think you’re making an interesting point about insurance and I’d like to know what you have done to address these issues. We have talked to a few credit insurance companies and decided to not focus on purchasing the insurance as for a factorer because it does not cover some fundamental issues which I go into below. Does the insurance provider you work cover these cases?

  • Credit insurance typically only covers the default of the buyer not of the supplier. Do you use a lockbox to make sure that supplier’s bankruptcy would affect the repayment of the invoice?
  • It also typically covers a buyer disputing the payment for other reasons such as faulty goods or services delivered.
  • You mention that you verify the invoice with the tax authorities but just checking that the invoice exists in their system doesn’t mean that it isn’t fraudulent. Insurance companies don’t insure against fraud by any of the involved parties usually.

With all of these downsides the credit insurance typically turns into a rather expensive product that doesn’t cover a large part of the risk for the lender. Therefore in our experience factoring businesses don’t usually buy credit insurance on their assets. Insurance can easily cost 2.5% on the total amount. For an invoice with a maturity date of 60 days that’s 15% annualized. At the high end of factoring you will typically pay 20%-25% APY which means that you would be left with only 5% of interest after paying for insurance but still haven’t covered the risk of fraud and other issues. I’m quoting these numbers from the modelling we did for our assets. @Marco how does the insurance product work you use? Do you have these issues addressed otherwise?

We decided to focus on solving for all of these issues above by building the insurance on chain by introducing a structured finance approach: using two tranches. We are open to add credit insurance if this is a financially beneficial decision for both the asset originator and the investors (Maker).

Most of these assets I assume are denominated in EUR, how do you insure the exchange risk? Are you purchasing a DAI hedge for it?

On the technical solution you mention that your model is simpler and uses ERC721s for individual assets. Are you suggesting that a vault is collateralized with different NFTs? If yes, how would auctions work to sell of NFTs when a vault is underwater?a

I agree with you here, and while I definitely would not say we are just focused on music streaming and freight invoices, hopefully there will be many different collateral types not just by Centrifuge but also others. We have done first pilots with different asset classes such as fix & flip mortgages (see our Aug 2019(!) announcement) and real estate, a segment that when the macro-economic climate stabilizes a bit is definitely interesting to look at again.



your proposal for insured tokenized invoices is interesting.
I do have a question:
How can Maker be sure the invoice is actually insured? There needs to be some kind of information flow between the insurer and Maker, highly preferable with a proof-of-insurance of sorts on the Ethereum blockchain. Could you explain this bit in more detail?

1 Like

hey @marco and @jack do you have any comments on this before the voting period is open? Would love to understand a bit better how WizKey works.

1 Like

Dear @spin and @Planet_X, thanks for your questions and your patience. :slight_smile:
We had other calls with the insurance company we’re working with and we double-checked some of the issues you’ve pointed out. As we’re very busy right now, we’ll get back to both of you with thorough answers by tomorrow evening at latest.

1 Like

Thank you @Planet_X for your question.

In order for Maker to be sure that the invoice is insured, we developed a PoC in partnership with the insurance company to address the problem:

(i) step 1: target company (the “ Company ”) uploads the documentation related to the invoice on WizKey and creates an NTF (“ Token 1 ”), with all the information relevant to the invoice written in the payload;

(ii) step 2: the Company grants access to the insurance company (the “ Insurance Company ”) to the data room connected to the NFT and the token held in an escrow smart contract;

(iii) step 3: the Insurance Company carries out its risk assessment procedure and grants the insurance coverage over the invoice of the Company, signs the escrow smart contract and unlocks Token 1, that is sent to the Insurance Company wallet; the Insurance Company wallet is known to Maker;

(iv) step 4: the Insurance Company creates an NFT from its wallet that contains the payload of Token 1, then adds metadata related to the insurance (“ Token 2 ”) and sends Token 2 back to the Company; Token 1 is burnt;

(v) step 5: the Company sends Token 2 to Maker in order to open the CDP and use Token 2 as collateral.

We designed the above system in order to make sure that Maker can trace back the origination of the invoice on chain, the fact that the Insurance Company has insured the claim and receive the metadata related to the invoice and the insurance coverage in order to open the CDP; the “oracle” of the whole transaction is the Insurance Company, whose wallet is known, in order to avoid insurance frauds.

Hope this answered your question and helped to make the process clearer for everyone.



Hi spin and thank you for your question. Please find hereinbelow the thorough answers to the problems you’ve pointed out:

In the terms & conditions of the access to the DAO the company opening the CDP shall undertake to assign by way of security the invoice used, and insured, as collateral for the CDP in order to provide to the DAO / MakerDAO Foundation a security interest over the invoice itself; under EU insolvency law generally this security interest is valid in the context of insolvency of the company and opposable to the company’s creditors.

This is all true but we don’t see an actual problem here. It’s matter of fact that there are no insurance companies that insure against fraud, except for one specific case of identity defraudment.
In order to be sure that the invoice exists we make a double-check between the Italian Tax Authority (ITA) and the CRM used by the issuer (e.g. SAP Business One) and then the insurance company make a third assessment on the issuer to insure the invoice. This will basically solve one of the major problems of factoring which is the multiple spending of the same invoice with 2 or more factors.
Moreover, the pilot program will take place in Italy, where the issuance of fraudulent invoices is highly disincentivized through the system of “electronic invoices”. In fact the management of the company issuing the fraudulent invoice bears penal liabilities, risking from 1 year and 6 months to 6 years of jail. In terms of game theory and incentives this shall be a very good incentive not to provide false invoices; moreover the double check with the insurance company shall make the system quite robust.

We’re referring to the outright transfer of the ownership of the invoice (i.e. assignment without recourse), in which APY payments are far lower than 20%, attesting between 3%-7% APY (e.g. check this website of an Italian fintech company providing factoring solutions with the rates mentioned above). In case of funding of invoices with recourse the rates are closer to the one you pointed out.

With regard to the insurance costs we have very different rates, confirmed by the insurance company in our last call that we made yesterday in order to double check all our answers (thanks for the pretty serious questions!): the two ends are, very small enterprises with a percentage that may vary from 1.2% to 1.5%, which become 0.07% - 0,1% for big and international enterprises. For everything is in between the average percentage are 0,2%-0,5% on the total amount. The only case in which you have a 2% cost on the amount is when a company wants to insure a single invoice but this is not the case, as the insured invoices are the ones sent by WizKey to the original issuer.

With this numbers in mind we find useful to have insurance on the invoices to lower risks of insolvency.

Your solution for the insurance on-chain is very elegant for sure, but since the beginning we opted for the involvement of an insurance company to address some liabilities problem we saw. We will certainly deepen our knowledge in your on-chain solution in a further phase of the project, so there could possibly be your study on the use case proposed.
With respect to the exchange risks we decided not to take hedge in DAI for the pilot tests but we’re surely studying it, hoping in the meantime that Maker will release its EURDAI ;).

Correct, we want to use ERC721 as collateral for the vault, the value of which is displayed in the payload. The risk of default is strictly connected to the default of the insurance company, which is rated AA- as the US treasury bond, so it’s unlikely to happen. Anyway, if that should happen, we already contacted factors that shall be buyers of last instance of the defaulted insured invoices.

We may have been over-simplistic on saying that you focus on that segments, but we were referring to your proposals, which focus is quite different from ours or, better saying, we thought you were mainly focused on two precise segments of the market, which is not a bad thing per se and we were not insinuating it. Anyway we really hope that we could have a constructive collaboration in order to address the problems we’re facing to bring real-world assets onto the Ethereum blockchain and in MakerDAO.

Hope I’ve answered your questions and cleared your doubts. If something is still not clear, don’t hesitate to ask.


1 Like

Thank you for the response @Jack,

So if I read this correctly, a Maker smart contract will only need to compare the amount of Token 1 with the amount of Token 2 in order to check the validity of the insurance?
Am I correct?


Thanks for the answer here, I’ll take up a few things:

Insurance is typically a one time cost which I have annualized in my example. You mention that you target SMEs in Italy. So I’ll take the 1.2% number you’ve mentioned. If you pay a 1.2% insurance premium on a NET60 invoice that means you are effectively paying 1.2% over 60 days or 7.2% annualized.

You say that the APY on these invoices you are expecting are in the 3-7% range. Which means that the supplier pays 7.2% on insurance and 7% on the financing. Right? This is the point I was going to make, insurance easily ends up costing half of the cost for the supplier but in my experience doesn’t cover some of the largest risks involved in factoring.

I think we/youu’re mixing the two: recourse factoring means in case the factorer is not able to collect payment from the buyer then the supplier is liable to pay the amount. This should be the lower risk and therefore cheaper option but you’re saying that the APY for non-recourse factoring of invoices in Italy for SMEs is 3-7%?

Non-payment by a buyer can also have other reasons. For example it is quite common that an invoice is written upon shipping the goods but the supplier bears the responsibility of the goods being delivered in the expected timeline without any defects. If there is a defect in the product, the shipment gets lost or delayed then a buyer will not pay the invoice and an insurance company will not pay for it.

Who takes this risk in the solution that you are proposing here? Is this ultimately Maker? Do you have an idea of what yield Maker should be able to expect on these assets?

1 Like

Not exactly. The Maker smart contract should check that the Token 2 was sent from a known wallet (derived from a whitelist of wallets) of the Insurance company and then from the payload of the token it can derive all the relevant information to the invoice, being the payload of Token 2 composed of the payload of Token 1 plus the proof-of-insurance attached by the insurer.

1 Like

Hi Spin,

please find hereinbelow our answers:

I think there is a misunderstanding here; I will go a bit deeper with respect to the product our insurance partner is offering.

The insurance covers all the annualized cash flow of target enterprise, then each single invoice is insured (and then passed into Maker).

The discount rate that we represented are the actual annualized rates; hereinbelow the split between the annualized annual rate and the discount on a 90day invoice:

  • SME: annual: 1.5%/ 90day invoice 0,375%

  • Medium enterprise: annual: 0.5% / 90day invoice 0.125%

  • Large corporate: annual: 0.1% / 90day invoice 0.025%

We checked again today with the insurance company and the above data is all correct

The 3-7% rate of discount applied to the invoice is based on the assessment made by the factor on the supplier when the invoice is not insured, when the invoice is insured usually it goes very much towards 3%; In our experience many factors insure their overall invoice portfolio following the assignment thereof.
As said in my latest post, risks of fraud are highly disincentivized in Italy through electronic invoices, but you’re right when you say that insurance does not cover all the risks involved in factoring. Insuring the invoices anyway grants, by our standpoint, more reliability to the system in case of failure of any kind.

On a legal standpoint non-recourse assignment is a much stronger instrument in case of insolvency of the supplier and therefore factors use lower interest rates for such instruments as the assignment is opposable in the context of a bankruptcy; for this reason non recourse factoring towards SMEs is very costly, as the factor discounts through a higher interest rate the possibility of the SME going insolvent, which are higher than medium/large enterprises.

The average prices are the one in the link of CREDIMI in our last post (one of the most famous fintech factors in Italy)

The problems you mentioned are actual but in order to address them in the first phase we are doing things slightly differently, as:

  • Target company shall enter into a DAI purchase agreement with WizKey;

  • WizKey issues an invoice towards target company and insures it

  • WizKey tokenizes the insured invoice and uses it as collateral in Maker DAO

  • WizKey provides target company with DAI

  • target company repays the DAI to WizKey

  • WizKey repays the DAI to Maker DAO;

for this kind of product we shall expect an AY not higher than 3-7%.

In this way there shall be no problems of claims for defective products / shipments as WizKey shall provide target company with DAI.

In phase 2 target company (supplier) shall use directly its invoices with Maker DAO, without using WizKey as a proxy thereof; in phase 2 the legal framework shall be as follows:

  • target company insures and tokenises an invoice;

  • target company opens a debt position with Maker DAO and uses the insured invoice as collateral;

  • target company then repays DAI to Maker DAO;

Maker DAO position shall be then the creditor of target company, with a security interest over the insued invoice. The risk of Maker DAO is that both the following events occur on the sam invoice:

  • target company (supplier) goes into bankruptcy; and

  • debtor (buyer of the supplier) dismisses the invoice as the goods underlying it have not been supplied / are defective,

as, if only one of the events occurs, Maker shall still have plenty of coverage:

  • target company (supplier) goes insolvent: Maker has a security interest over the insured invoice;

  • buyer dismisses the invoice: Maker has still a claim towards supplier that is solvent and shall repay the CDP;

Also for this kind of product we expect a risk premium of 3-7%, but we are still working on the risk framework to model the precise risk premium.



1 Like