As a result of recent events, and particularly the default by Orthogonal Trading, we want to clarify how our platform and services are used across the on-chain credit ecosystem. To reiterate, Orthogonal Trading was not fully set up on our platform and not monitored by lenders using our infrastructure.
Our users are broadly segmented into two groups:
- Oracle Users: Rely on the scores from our Credit Evaluation Methodology
- Platform Users: Do their own underwriting using the platform
Credora’s platform provides infrastructure for ongoing counterparty credit risk assessments. This is the core of our business, and it enables us to provide credit scores for partner protocols.
The below graphic displays how any Credora user assessment methodology exists as a layer tangent to the Credora Platform. The graphic is simplified, ignoring the various metrics captured in each section. Oracle Users receive the ongoing outputs of our Credit Evaluation Methodology, while Platform Users selectively consume information as permissioned by borrowers, and perform their own assessment. Credora is of course not involved in deciding their respective assessment frameworks.
Oracle Users
Credora has an internal credit team responsible for constructing credit methodologies, and using underlying platform data to assess eligible borrowers. Our credit team is a user of the platform, and scoring well on the publicly available Credora methodology requires a substantial amount of transparency. The team condenses platform information into a credit score systematically, ensuring the underlying processes are the same for all Oracle Users. By taking this approach, the team aims to provide guidance for external capital allocators while respecting the sensitivity of granular real-time and financial statement information.
The credit evaluation methodology applies a 40% weight to information gathered via risk monitoring. As a result, scoring A or above (>700) requires a material amount of real-time data provision.
As outlined in previous posts, Credora utilizes real-time data as follows:
- Validate Reported Information: Reported assets and risk monitored assets are constantly benchmarked by the system, providing a real-time understanding of visibility.
- Evaluate Portfolio Risk: Key risk metrics including directional exposure and positional exposure are used to evaluate the borrower in the context of other information.
- Monitor Counterparty Exposure: Credora has information on the counterparty risk each borrower absorbs, primarily to trading venues, custody solutions, DeFi protocols, and other providers.
- Identify Signs of Stress: Large changes in metrics are automatically flagged by the system and alert the credit team to request more information from the borrower.
Platform Users
Outside of serving as a foundation for Credora as a credit oracle, the Credora platform exists as infrastructure for lenders and borrowers to bilaterally engage one another and do their own underwriting. Many platform users, including Maple pool delegates, have their own credit methodology. This is also the state in traditional markets, where different credit underwriters utilize different assessment methodologies.
We have spent the past two years attempting to educate various lenders on why real-time data is essential for proper risk management. While Maple Pool delegates have understood the value of our infrastructure, many lenders in the space have expressed skepticism that can be summarized as follows:
- Relationship Prioritization: Many lenders are convinced that relationships are a key component of credit underwriting. Effectively, that trust comes through in-person meetings, rather than validating data.
- Incomplete Data: Many lenders have historically argued that seeing less than 100% of someone’s reported assets is useless. The premise of this argument is flawed. Currently, without real-time data, there is a complete reliance on reported financial information. Although we can debate the shape of the utility curves for real-time data (i.e. the value of 10% vs. 50%), it is clear that they are upward sloping. Our approach is not that the ‘balance sheet shows X, data shows 30% of X, so data is flawed’. It is that ‘balance sheet shows Y times more assets than what is validated, so there is uncertainty in the validity of the balance sheet’. It is odd to look at any data in isolation, regardless of the source. If the data is incomplete, we do not proceed unless we have evidence and a valid explanation for why it is incomplete.
This approach ultimately results in a more thorough understanding of the borrower activity, and as incentivized by the methodology, a more robust set of data. The Risk Monitoring section effectively modifies key risk variables according to the extent that they can be validated, resulting in conservative outputs where financials indicate a different picture.
We recognize the challenges of underwriting in this industry, and appreciate that there are many approaches to assessing borrowers. Our platform aims to support these different approaches by facilitating structured data share and reducing information asymmetry.
Conclusion
For Oracle Users, Credora upholds the standards that are publicly available in our methodology documentation. Our team is constantly iterating on the model, and following systematic processes to score borrowers uniformly.
Credora is incapable of forcing our standards on Platform Users. For this audience, we operate infrastructure that facilitates information sharing, and unique technology that aggregates real-time data while respecting privacy. If it is required by their assessment process, it is the Platform Users’ responsibility to request more information through the platform. We are incapable of deciding a Platform User’s standards.
Maple pool delegates are active on the Credora platform. Pool delegates have their own assessment methodology and use the Credora platform to supplement their processes. They monitor multiple borrowers, but that does not mean that they require risk monitoring from all borrowers. They make their own lending decisions, and do not consult Credora on them.
