Rounding of account holdings

This 100% accurate rounding is going to take some getting used to....

"Purchase loan part 13179099 (old id 11277603) for 0.9999999999999999999999999999999999928016 GBP - annualised rate 10, loan: Burnley Wind Turbine (83)"

Why is it necessary to buy and sell fractions of a penny, seems over complicated and ridiculous to me, especially as the loan book only displays whole pennies.  Hopefully I will be able to sell all the fractions when the system goes live again

If you invested £10.66 (I worked this out earlier and can't remember if that is the exact figure) in one of the 6.75% BTL loans you currently earn £0.06999 per week. If you round down you earn £0.06. This is considerable reduction (in percentage terms). One day AC might have lots of available loans and we might want to diversify across many of them in which case rounding errors become significant. Even ZOPA many years ago had a procedure for rounding the interest correctly. I started off with quite a small test investment in AC. If others do the same and the interest they earn is much lower than they expect they might go elsewhere.

But related issues apply to amortizing loans, though: capital repayments quickly result in fractions of pennies of loans being held.  So either way you end up with fractions of pennies being held.  I guess buy/sell could be artificially limited to whole pennies only, but it doesn't make much odds - in fact it might prevent you selling out completely.

<START OF RANT>

Behind the scenes it's up to you what you do. But this level of "accuracy" is ridiculous. In fact of course 0.99999999999999451098000000 is not an "accurate" figure. It is itself a rounding error of the type you used get when you asked a calculator to add 1/3 and 2/3. The calculator should give 1 as the answer, but instead it gave 0.9999999 (they've got smarter, and some now store a few more decimal places than they display). Technically the calculator's answer is an error and even if it's smart and displays 1, somewhere in its memory banks that 1 is in fact 0.9999999999999999.

Be that as it may, the energy expenditure on calculating 0.0000000000000000000001 pounds and storing it as an entry, or value, with a corresponding ID in an SQL database is higher than the monetary value represented by several orders of magnitude. This in itself is a good argument for us mortals to realize that the accuracy of any digital system is always only an approximation of an analogue world.

Let's get real, shall we? We can only spend pennies. The ability to spend half a penny disappeared somewhere in the 1970s in the UK. So there really is no point dividing loan parts up into anything smaller than a penny, while another four decimal places would be absolutely sufficient to ensure that interest calculations on those penny holdings are right enough for us not to care about them. Personally I don't care about any fraction of a penny. I don't want to know about it. I don't want quintillionths polluting my spreadsheets and downloads! Other systems allow minimum loan holdings of £10. Some allow £1. Only obsessive-compulsives would care about anything less than a tenth of a penny.

I do, however, care about the stability of the Assetz database. If all the loan parts start "decaying" into micro, nano, pico, femto, atto, zepto or yocto loan parts, the Assetz servers will very soon turn into a white-hot mass of molten lava just trying to calculate the interest due to the quadrillion different yocto parts polluting the database.

</END OF RANT>

All platforms have to deal with the same issue.  If you have £100 invested in a loan earning 10% per annum then how much interest are you paid each month?  If the loan amortises over 36 months how much principal do you receive back if each payment is rounded down to the penny?  When I coded FC we kept track of all the little extra bits and added them up after each payment so that when they added up to a whole penny they were distributed to the lender.  FC have (or had at the time) a very simple loan model so it worked well enough and hit the complexity.

When developing AC I followed a similar approach but we quickly out grew it as we developed deferred interest on loan unit sale, a more complex loan model, being able to dynamically change the loan model, etc.  Each time anything changed it meant recalculating complicated repayment schedules keeping track of all the fractions.  Also because principal repayments were rounded down, as with interest, it meant that loan holdings were always overstated.  If you had £100 invested it could actually have been £99.01.  Because we had a maximum loan unit size of £100 that meant those with lots of loan units or large sums invested could have had a fairly large discrepancy.

Ultimately we switched to the simpler solution (code wise) of just storing the full fractional amount against each user's balances.  This gave us the flexibility we needed, and allowed us to also introduce the splitting and merging of loan units to facilitate sale on the aftermarket, but exposes lenders to some of the complexities of how platforms need to work.

I'm sure most platforms work either in the same was as FC (and AC at launch) or like we currently do.  Some may just keep the fractions of a penny or do something else that I haven't even thought of.  I believe Zopa show figures to 8dp so presumably use a similar implementation to us (I don't personally invest with them so I don't know for sure).  The main reason we have an issue of sorts is simply that we switched approach half way through the life of the site and that has had a knock on effect in terms of information that used to be displayed not quite tallying with what is now displayed.

In terms of server load we allow loan units to be merged together so in terms of live data each lender usually only has one loan unit.  Thus negating any issues with small divisions of loans.

So that's a busman's holiday you are on then chris.