Qualitative risk assessment plays a crucial role in the categorization of the likelihood of a certain adversarial attack. It also helps in mitigating low-risk exposures and avoiding a misnomer of an address. Therefore enabling a relatively transparent organizational method of transactions based on the risk they present is paramount. For that, we need a mechanism that would allow us to accurately, collectively, and categorically sort each potential adversarial attack based on the risk factor. Therefore we decided to introduce the Relative Scoring Mechanism (RSM).
With RSM each address is gauged based on the totality of transactional activities and the risk can exponentially increase or decrease depending on the “tier” of a risk they have engaged in. In essence, then, each transaction is appraised and given out a “score”. With a certain threshold exceeded, the address can be assigned a “risky” index that would delineate that a given address can pose a substantial threat.
The risk score is calculated based on the number of transactions initiated by a user “T” and the quantity of those transactions that exceeded the threshold of risk represented by “r”.
Simple Risk Assessment:
An issue arises with new users who have non-existent scores because of the absence of any prior transactions. The limitation of this kind is also further aggravated if we are to consider that one non-threat transaction will immediately change the score of a given user to 1 which is the maximum possible value that renders a particular user “risky”. The opposite also engenders a problem since one misgiving transaction on the side of a user will cause the score to substantially go down. That might create a discordance in assessment since a theoretical user with a large amount of non-risky transactions and, assuming, one risky will be deemed by the system as a more risky player than a user with only one non-risky transaction in the totality of his/her transaction history. Therefore the trust factor of our simplistic assessment mechanism might invalidly consider the former user as posing more threat than the latter despite the first user leaving more footprint and more room for qualitative assessment overall.
In order to rectify this issue, we need to discern and examine a transaction in a more complex and complete way.
Complex Risk Assessment with the introduction of Case Category (Reputation Score):
S = defines the reputation score of a given address. The reputation score is calculated by considering values such as the total amount of transactions by the same user and the percentage of those transactions being risky. The threshold of risk is calculated separately for each address based on the tiers and their respective points. The binary system of risk calculation still remains so there are only two possible outcomes: risky or non-risky. T = refers to the total transactions issued by the given address. R = pertains to the number of transactions issued by the address that involves any of the risk tiers and supersedes the threshold of risk.
Each tier within the Case Category is representative of and adds to the totality of score calculation. Based on the score and whether this score indicates a higher or lower risk exposure, the added “points” will influence the verdict of the assessment.
Case Category (Reputation Score)
A case is a reported event of illicit activity that encompasses an array of addresses. Each case is an instance of a recorded transaction of a given address in HAPI SC as well as its immediate transactional activity recorded on the blockchain.
Employing Reputation Score is salient in two ways: firstly, it empowers a more reliable gauge on the address’ risk of posing a threat, and secondly, it works complementary to the simplistic structure, making less room for error.
Example of Risk Scoring
Exact points given and classification in general might be subject to change.