You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm speculating, no data or feedback backs this up.
I realized that the current logic to evaluate receivables for the possibility of an delinquent attitude of the debtor is particularly benevolent towards Nodes that act actively but with not so much focus on how much they pay in a single transaction. I'll explain better:
If a Node owes money in some kind of excessive manner and we've had to impose a ban, it can take a transaction of any size that will have an effect on this ban to be lifted, at least for some small amount of time. Why? Because when our Node detects the transaction and process it through the database it also adjusts the last_received_timestamp column to the time when the scan is being processed.
However, it is one of the parameter to check delinquency and the adjusted timestamp translates newly as "considerably young debt" which in turn means our Node will ignore this account despite the size of the debt still may remain critical and much above the requested limits. Its age makes an excuse. This is wrong and may attract hustlers to think how they could exploit this to their benefit.
An extreme situation, that might not ever be reliably applicable in the field, involves a malefactor that would try to send almost valueless payments to the creditors in such a frequency that the debt on his account could keep on constantly growing while the refreshing payments would make it always look like a very young debt that would stay away from the radar. Here I'm referring to the period of time made up by joining the maturity_threshold_sec (time until a payable is ignored from the perspective of the payer) and payment_grace_period_sec (how much extra time to the previous limit we give the debtor before we use a ban on them). This in total may be quite a long time.
This strategy would work well but is rather of luck in reality because it depends heavily on the setup of the scan cycles on the creditor's side. The idea of frequent payments is canceled out if the intervals of the receivable scans are comparably long. Stepping into the world of sci-fi, the debtor could figure out what the intervals are from observing how long it took until his ban was taken off to use this information for making a decision if the strategy can pay off.
Possible solution:
We probably shouldn't mark the last payment completely regardless but we should also check how effective the payment was. The parameter would become more of "the last timestamp when a payment left an insignificant amount of still owed money". Practically it can be implemented as anytime when the debt comes below one of the payment thresholds parameters, called permanent_debt_allowed.
The text was updated successfully, but these errors were encountered:
I'm speculating, no data or feedback backs this up.
I realized that the current logic to evaluate receivables for the possibility of an delinquent attitude of the debtor is particularly benevolent towards Nodes that act actively but with not so much focus on how much they pay in a single transaction. I'll explain better:
If a Node owes money in some kind of excessive manner and we've had to impose a ban, it can take a transaction of any size that will have an effect on this ban to be lifted, at least for some small amount of time. Why? Because when our Node detects the transaction and process it through the database it also adjusts the
last_received_timestamp
column to the time when the scan is being processed.However, it is one of the parameter to check delinquency and the adjusted timestamp translates newly as "considerably young debt" which in turn means our Node will ignore this account despite the size of the debt still may remain critical and much above the requested limits. Its age makes an excuse. This is wrong and may attract hustlers to think how they could exploit this to their benefit.
An extreme situation, that might not ever be reliably applicable in the field, involves a malefactor that would try to send almost valueless payments to the creditors in such a frequency that the debt on his account could keep on constantly growing while the refreshing payments would make it always look like a very young debt that would stay away from the radar. Here I'm referring to the period of time made up by joining the
maturity_threshold_sec
(time until a payable is ignored from the perspective of the payer) andpayment_grace_period_sec
(how much extra time to the previous limit we give the debtor before we use a ban on them). This in total may be quite a long time.This strategy would work well but is rather of luck in reality because it depends heavily on the setup of the scan cycles on the creditor's side. The idea of frequent payments is canceled out if the intervals of the receivable scans are comparably long. Stepping into the world of sci-fi, the debtor could figure out what the intervals are from observing how long it took until his ban was taken off to use this information for making a decision if the strategy can pay off.
Possible solution:
We probably shouldn't mark the last payment completely regardless but we should also check how effective the payment was. The parameter would become more of "the last timestamp when a payment left an insignificant amount of still owed money". Practically it can be implemented as anytime when the debt comes below one of the payment thresholds parameters, called
permanent_debt_allowed
.The text was updated successfully, but these errors were encountered: