Overview
From 2022, a new credit limit algorithm will be available on PRISMA: namely, Stacked Credit Limits. When applied to a specific credit framework, this algorithm significantly changes the way overlapping limits are factored in every transaction.
In brief, instead of subtracting the monetary amount of each transaction from all concurrent credit limits at the same time, the Stacked Credit Limit Algorithm considers all concurrent credit limits within a framework as a unit and charges the whole unit according to a system of priorities which shall be explained in detail below.
The Stacked Credit Limit Logic
To understand this new method of calculation, it would be useful to contrast it with the standard credit limit algorithm.
Consider, then, the following credit limits:
To better illustrate the situation, we could graphically represent them in terms of their validity as such:
Now, imagine these credit limits are assigned to you and you would like to conduct these transactions:
How would these transactions be deduct from your credit?
1) Regular Credit Limit Logic
According to the regular credit limit method, the monetary value of each transaction would be independently subtracted from each concurrent credit unit. In other words, if the runtime of a transaction stretches over several simultaneously active credit limits, then each of those credit limits will be independently charged.
In our example, T1 will deduct 150 from Limit A, 150 from Limit B and 50 from Limit C (since it is active for 1/3 of the runtime of T1).
The table below reflects the state of your credit situation after T1:
Therefore, according to the regular credit limit algorithm, T2 and T3 would fail. You would not be able to proceed with those transactions due to a lack of credit.
2) Stacked Credit Limit Logic
Now, through the Stacked Credit Limit method, all concurrent credit limits are factored as a single unit (a stack, if you will) and used one at a time in accordance with their expiration date.
Thus, this algorithm does two things:
1) it stacks the credit limits from earliest to latest expiration date;
2) it slices the longer credit limits based on the length of the shorter ones (dotted grey lines on the graph).
3) it divides the monetary value of each transaction based on how the runtime overlaps with each timeslice.
So, when you conclude a transaction on the platform, its value is divided and subtracted from the stacked limits following these timeslices. However, for every timeslice, the algorithm prioritizes deductions from credit limits that expire earlier before it spills over to the ones below. In brief, given the runtime of a specific transaction, the system goes through each timeslice and charges the proportionate amounts to the limits from earliest to latest expiration date.
The graph below illustrates how that works:
The amount of transaction T1, which cost 150, was divided by three, because its runtime stretches over three credit timeslices. In the first timeslice, 50 were subtracted from Limit B, since Limit C was not yet valid. Then, Limit C was charged 50 in the second timeslice because it expires earlier than B. In this case, there was no need to spill over to Limit B. Finally, Limit B covered the last timeslice. In total, 100 were deducted from Limit B and 50 were deducted from Limit C. Limit A was not charged at all.
Therefore, the final state of your credit limits after T1 is:
If you now proceed with transaction T2, the money would be deducted from your credit stack as follows:
As in the previous transaction, T2, which cost 100 and runs for three months, will be divided in three due to the arrangement of your credit limits. In the first timeslice, 33,3 will be subtracted from Limit B, since it is the topmost limit in that period. Then, 33,3 will be charged from Limit C without spillover. Finally, the algorithm will attempt to deduct the final 33,3 from Limit B. However, that would bring its used amount to 166,6 while its total amount is 150. So, 16,6 will spill over to Limit A.
The table below represents the state of your stacked credit limits after T2:
Finally, after concluding these two transactions, you still wish to conduct transaction T3. The graph and the table illustrate how this transaction will affect your stacked credit limits:
T3, which cost 50 and spans one month, will not be divided given that it is covered entirely by Limit C, the shortest credit limit. First, then, the algorithm will try to deduct 50 from Limit C. Yet, Limit C only has a remainder of 16,7. So, that amount is subtracted from it and the rest spills over to Limit B. Limit B, however, has been completed used in the previous transaction. So, the remaining value spills over to Limit A.
The table below represents the state of your stacked credit limits after T3:
Thus, by the stacked credit limit logic, all three transactions are possible. If you now decide to cancel T3, the limit at the top of the stack - that is, the limit with the earliest expiration date - will be reimbursed first.