sl75
Posts: 2,092 
Likes: 1,245
|
Post by sl75 on Feb 18, 2015 20:59:54 GMT
In which case (SL75) it is even stupider to put all the bids/rejected bids through the same transaction loops as real money needs to go through. Nope I probably couldn't do a million cloud synched transactions in just a few minutes, but I think the average bank, credit card company, or stockbroker could possibly do it in a fraction of the 'all day' that FC takes. As I understand it, bids / rejected bids are equivalent to a "payment authorisation", not to a full transaction - the money would never actually be transferred out of your account, merely reserved within it (with the back-end payment systems set up to ensure that such authorisations are not made in excess of the available balance). Conversely, when repayments are made, these are full transactions that do need to move money. Having the bids registered on the virtual banking system would seem necessary, in order to ensure funds really are available at the point the borrower comes to draw down the loan. Much as another system could be designed where bids are NOT required to be backed by cash (making bids have roughly equivalent status to the "pre-bids" on AC's old system), that is not the system we currently have. As long as bids must be verified to be backed by real money, the bidding system must interact with the systems that handle the real money in order to reserve some of that real money.
|
|
|
|
Post by GSV3MIaC on Feb 18, 2015 22:19:28 GMT
Yes I know it's not the system we have, I just think it should be, because it would (should) unload the servers and avoid stuck bids. It might even allow the real money transactions to process faster. It would also avoid the accountancy no-no of retroactively deleting transactions.
|
|
sl75
Posts: 2,092
Likes: 1,245
|
Post by sl75 on Feb 19, 2015 0:03:24 GMT
Yes I know it's not the system we have, I just think it should be, because it would (should) unload the servers and avoid stuck bids. It'd certainly result in some very interesting market dynamics... Presumably if unfunded bids are to be permitted as suggested, the system would at some point need to determine which indicative bids to convert to real bids and which to cancel due to lack of funds. Until that moment, indicative bids would effectively appear and disappear depending on movements of funds in the respective lender accounts, so the borrower couldn't be certain of receiving full funding or of what rate they'd get until that moment, and lenders wouldn't be able to determine the top rate in order to undercut it by 0.1%, as the effective top rate would fluctuate depending on the collective funding level of all lender accounts. I can certainly see there'd be a lot of benefits, but it's not clear whether they outweigh the drawbacks - whether it would result in something "better", "worse", or merely "different".
|
|
blender
Member of DD Central
Posts: 5,719
Likes: 4,272
|
Post by blender on Feb 19, 2015 10:26:15 GMT
It is hard to discuss and assess improvements when we do not have a clear idea of the configuration of the system to be improved.
If we accept that the client accounts are kept on a third party system accessed by API - or some physically separate secure system, then it is only required to handle real transactions - actual changes in cash balances for clients, presumably formed from a sequence of transactions generated by FC's platform and resulting in fully auditable balances for lenders and borrowers. It need know nothing of loans and bids and interest rates etc except as data logged with each transaction. It need know nothing about available funds etc. It is clear that we see nothing of this except through the platform, and that the transaction log we see is not our client account but a series of transactions, some real like monthly repayments, some not real such as bids, plus a few balances which might be generated either by the platform or by the platform involving balances called up from the client accounting system.
Consider the possibility that the bidding process is entirely a matter for the platform and that our lender accounts, proper, are only debited when the loan is drawn down. What we see in our transactions is not an auditable cash account with unacceptable practices such as deleting transactions (failed bids and double sales), and misdated transactions (bids when made rather than when drawn down as cash). It is rather just a log of transactions generated by the platform, some representing real cash transactions which have been logged on the client account (repayments) and some representing reservations of funds, such as bids, or even accruals. These accruals are generated from lender holdings of loan parts, each of which is subject to accrual of interest calculated by the platform to fractions of a penny on a daily basis. Consider the possibility that the division of the lender cash balance between available funds and bids may be something entirely local to the platform, and need not involve our real accounts in a client accounting system - until the loan is drawn down.
This does mean that there would be two sets of balances - the indicative ones calculated by and given on the platform, and the real ones held on the client accounting system. Of course there is some duplicated effort involved, but not much extra.
|
|
|
|
Post by GSV3MIaC on Feb 19, 2015 11:25:39 GMT
Yes I know it's not the system we have, I just think it should be, because it would (should) unload the servers and avoid stuck bids. It'd certainly result in some very interesting market dynamics... Presumably if unfunded bids are to be permitted as suggested, the system would at some point need to determine which indicative bids to convert to real bids and which to cancel due to lack of funds. Until that moment, indicative bids would effectively appear and disappear depending on movements of funds in the respective lender accounts, so the borrower couldn't be certain of receiving full funding or of what rate they'd get until that moment, and lenders wouldn't be able to determine the top rate in order to undercut it by 0.1%, as the effective top rate would fluctuate depending on the collective funding level of all lender accounts. I can certainly see there'd be a lot of benefits, but it's not clear whether they outweigh the drawbacks - whether it would result in something "better", "worse", or merely "different". I don't advocate that unfunded bids would get through - just that it is the lenders job to ensure they have the funds (or can provide a DD / debit card so FC can collect it). Failure to meet your obligations at the end of the auction would get you into trouble, just like it will at Sothebys .. worst case (repeat offence?) your account / bidding ability gets removed. Any 'unfunded' bids either get picked up by FC's underwriting arm (see property loans!) or else they 'roll back' the cutoff edge and some knocked out bidders get lucky (if they want to) .. the latter might affect the borrower rate though. p.s. for blender .. the daily calculations of accrued interest on every loan part on the system (with rounding to god knows how many digits carried forward somewhere) is another example of self inflicted and avoidable nightmares on the computation front .. although it doesn't affect the transaction reports, it presumably has to be done in order to give everyone sight of their accrued interest, and to price loan parts for sale. Be much simpler to adopt the (stock exchange) model 'interest does not exist until paid, and then it goes to whoever owns the part at that time' (although I guess that may have some taxation implications, as it does for stock and bonds). Any doubts, you could sell 'XD' (or in this case 'XI').
|
|
blender
Member of DD Central
Posts: 5,719
Likes: 4,272
|
Post by blender on Feb 19, 2015 11:58:07 GMT
Selling 'XI' in a lending business seems rather strange and impractical.
My main point was daring to disagree with SL75 (risky with such knowledge and competence) in the following:
"Having the bids registered on the virtual banking system would seem necessary, in order to ensure funds really are available at the point the borrower comes to draw down the loan.
Much as another system could be designed where bids are NOT required to be backed by cash (making bids have roughly equivalent status to the "pre-bids" on AC's old system), that is not the system we currently have. As long as bids must be verified to be backed by real money, the bidding system must interact with the systems that handle the real money in order to reserve some of that real money."
I am saying that you can, and FC may well do, have a system which backs bid with a calculation of cash without having to register bids with 'the systems which handle real money'. Undesirable - because errors might creep in (surely not) but possibly the lesser of the two evils - the other having to handle all real time bidding over a link between two systems, one of which is not really interested until drawdown.
|
|
sl75
Posts: 2,092
Likes: 1,245
|
Post by sl75 on Feb 19, 2015 17:35:14 GMT
I don't advocate that unfunded bids would get through - just that it is the lenders job to ensure they have the funds (or can provide a DD / debit card so FC can collect it). That would be an administrative nightmare. A £500k loan cannot draw down because a lender with a £20 bid provided invalid DD / debit card details? Seriously??? It seems you're calling for something closer to "shadow bids", rather than something like "pre-bids" that was in the comment you'd agreed with. Shadow bidding simply doesn't scale beyond a small group of underwriters, as AC seem to have discovered. If unfunded bids are to be allowed at all by retail investors, the system must explicitly allow for unfunded bids getting through, and it will quite simply not be acceptable to have these hold an entire loan agreement to ransom. One obvious solution to that would be simply to ignore those bids, building the final loan from the lowest FUNDED bids, either at the scheduled end time, or at a point of the borrower's choosing, at any point when at least 100% of the loan value is available in FUNDED bids. As mentioned before, this would have a number of interesting side-effects, as lenders would effectively be able to bid at any valid rate at any time, with no absolute certainty of what the highest rate included would be until the auction actually closed - leading to more "honest" bidding and less "strategic" bidding. p.s. for blender .. the daily calculations of accrued interest on every loan part on the system (with rounding to god knows how many digits carried forward somewhere) is another example of self inflicted and avoidable nightmares on the computation front .. although it doesn't affect the transaction reports, it presumably has to be done in order to give everyone sight of their accrued interest, and to price loan parts for sale. That part seems to be something that FC have got nailed from day 1. If you know the current date, the date of the last repayment and the rate at which interest is accruing from that date, you can calculate the interest due dynamically, without any need to write any data to a database anywhere, and based on observed behaviour of FC's systems, it seems that's what they're doing in the back end (it could, for example, be encapsulated in the behaviour of a class representing a "loan part" object, where a handful of properties are directly stored as database fields and the rest are dynamically calculated on demand). As you said in your other post, such basic calculations involving adding numbers, etc. are something that even a simple computer can do many thousands of times in a fraction of a second (even counting the amortised time to load records from a local disk cache and write them back with the new value). I don't think FC have any nightmares in this area (unlike some others who appear to directly store accrued interest values in their database fields, so need a process to update them overnight....)
|
|
|
|
Post by GSV3MIaC on Feb 20, 2015 11:15:21 GMT
I don't advocate that unfunded bids would get through - just that it is the lenders job to ensure they have the funds (or can provide a DD / debit card so FC can collect it). That would be an administrative nightmare. A £500k loan cannot draw down because a lender with a £20 bid provided invalid DD / debit card details? Seriously??? Now you're being silly .. FC solutions Ltd or whatever they are called is quite capable of putting their hand in their pocket for the £20, (or ion the case of some property loans, £2m) even if only on a very temporary basis, and they would then take steps to make sure the bidder didn't do it again (there is a lot of floating cash in the system already, so I doubt any cheques would bounce) .. or, as you say, we could fall back to the lowest funded bids (assuming that person wanted the extra). Either way has got to be better than the in/out/in/out transaction bouncing we see today. On the accrued interest, yep, I guess they could (and probably do) calculate them on demand (although some platforms don't?) .. 'demand' though has got to be quite often for parts on the secondary market, unless they are caching the results too. Again, I prefer the 'there ain't no interest until it is paid' model.
|
|
blender
Member of DD Central
Posts: 5,719
Likes: 4,272
|
Post by blender on Feb 20, 2015 12:38:28 GMT
Accrued interest total is shown every time we log on, or go to the summary page. Do they do a calculation for each loan part held and add that up when you log on?
And when I ask for a page of 500 loan parts matching my criteria, and the accrued interest is included in each and every part, do they calculate all of them especially for me and recalculate each buyer rate?
And why when I purchase a loan part do I have to pay for the accrued interest, rather than taking my share of the risk that the next monthly repayment may not happen?
Perhaps because there could be a large database of loan parts, containing, inter alia, a set of balances (don't forget the roundings) which are updated routinely daily and when a relevant event occurs (like a sale). The system seems to live in the present, ie has no memory of past states or events other than logs of transactions. Similarly there should be a database of lenders with balances updated in the same way.
Or at least that's how I see it working, from observing is functions.
|
|
|
|
Post by GSV3MIaC on Feb 20, 2015 16:27:44 GMT
When you buy a loan part you take on ALL the risk that the next payment might not happen. I guess they could apportion the interest (if/when received) to all the folks who owned the part during the period (rounded to the nearest day, or hour, or minute?) but that'd be messy and require history keeping. Or we could have parts sold, as I said someplace 'XI', where the seller keeps the interest (and the risk) for that month. Make for a whole new and different flipping strategy (although it'd share a lot of features with the cash-back parts ... i.e. collect up-front (in the XI case it'd be the supposed interest) and then sell at a discount ASAP.
The accruals, roundings, uneven month lengths, and wandering payment dates make 'real' (i.e. totally accurate) IRR/buyer rate/part value calculation a nightmare, whether you do them all once a day, or on demand.... viz the 8% interest only parts selling at par at a quoted 7.9% rate. (well, closest I managed to get was about 7.96%, but I guess display truncation, &/or unique sub-penny rounding errors, could get it from there to 7.9%).
|
|
adrianc
Member of DD Central
Posts: 10,015
Likes: 5,144
Member is Online
|
Post by adrianc on Feb 20, 2015 17:01:18 GMT
Accrued interest total is shown every time we log on, or go to the summary page. Do they do a calculation for each loan part held and add that up when you log on? And when I ask for a page of 500 loan parts matching my criteria, and the accrued interest is included in each and every part, do they calculate all of them especially for me and recalculate each buyer rate? And why when I purchase a loan part do I have to pay for the accrued interest, rather than taking my share of the risk that the next monthly repayment may not happen? Why would it need to be done per part? Could the accrued interest not be stored for each loan, as x % of the outstanding capital (or even for each original £20 multiple), then just multiplied by the outstanding capital or the number of £20 chunks?
|
|
blender
Member of DD Central
Posts: 5,719
Likes: 4,272
|
Post by blender on Feb 20, 2015 17:54:06 GMT
I think not. The problem is that at each repayment date the interest earned is at some number which is a calculated to at least tenths of a penny, and the amount paid is either higher or lower than that earned. So FC must carry forward a rounding credit or debit against loan parts to which is added the next month's payment due for the loan part and so on. The problem of doing this per loan is that there are many different loan part sizes and many different rates of interest that apply. You will find for example that even at the same interest rate, the first payment for a £40 loan part can be a penny more or less that twice that for a £20 loan part. If you did the same each month some parts would systematically benefit each time. So you have to carry forward the roundings for each loan part separately. The same applies to fees and principal repayments. And of course the total monthly repayment is fixed in total and cannot be divided among all the loan parts with an exact number of pence to each, so there must be a rounding at the loan level with some roundings account going plus/minus from month to month.
If you hold a balance for each loan part you do not need a history for it. When it comes to the next repayment, you just calculate the monthly accrual, add it to the roundings carried forward, and either pay out, a whole number of pence and carry forward the roundings to the next month. If the part is sold you do a similar sum for the part month, pay the whole pence to the seller and adjust the balance carried forward with the buyer. Job done (unless a flaw which others will spot).
Now try doing that with wholly calculated values. You will need to calculate the total entitlement to date, since draw down, then calculate the amount paid to date, month by month in whole pence, then compare with the amount earned to date with the total paid so far, pay the pence rounded as appropriate. If that is possible (I would not know, having done my exams with a slide rule) then you would have to forget about the errors caused by sales, of which you have no record.
Of course it is much easier to calculate without the roundings problem - but we have been told by FC in FAQ that roundings are carried forward in some way. Personally I think roundings and sales may kill the idea of calculated values.
|
|
sl75
Posts: 2,092
Likes: 1,245
|
Post by sl75 on Feb 20, 2015 18:12:45 GMT
Of course it is much easier to calculate without the roundings problem - but we have been told by FC in FAQ that roundings are carried forward in some way. Personally I think roundings and sales may kill the idea of calculated values. That calculated values are used can be easily observed on any day of your choosing at midnight. The value of every single loan part instantly updates at midnight - something only possible if either: - a process has been beavering away in the hours preceding midnight working out what the "after midnight" values will be [and storing them - the part that takes the time - in a second copy of the database ready to switch in at midnight] - the values are calculated "on demand". FC does not allow overpayments, and does not adjust the repayment amounts for other events (even saving up partial payments until a "full payment" can be processed. This all points to the entire payment schedule having been calculated in advance, and the live site simply using calculations based on how far along the payment schedule we are. A single database field saying "loan XXXX has now received NN repayments" would automatically cause the value of every single part of that loan to update the next time it is calculated. These calculations are trivial once the loan payment schedule is known - the necessary multiplications and additions are no more complex for a computer than building the text that it sends out to you in the form of a web page, or than performing the database queries necessary to know what information to send you. There is even some direct evidence for some displayed fields being calculated rather than pulled from a database.... if you look at the list of loan parts sold, the premium column shows a % and a £ amount. The £ amount is calculated, and it uses the wrong capital value (capital value of loan part NOW, rather than capital value of loan part at time of sale), so loan parts that were sold in previous months show the wrong value in that column. Conversely the sale price must be directly stored, as this does not change.
|
|
blender
Member of DD Central
Posts: 5,719
Likes: 4,272
|
Post by blender on Feb 20, 2015 19:38:36 GMT
Thanks for your reply, SL75. I will take some time to consider it and may stay up late to watch the numbers change. It is possible to store today's and tomorrow's changing values in a loan parts file and switch at midnight, which gives all day to calculate next day's values. But I do take your point about a pre-calculated repayment schedule for each loan part - we have such a thing available in my loans and I had never looked at it in all my FC time. Mine is 34,000 entries and I have probably just killed the system for everyone else.
Will think about it, but it may resolve my roundings issue.
|
|
david42
Member of DD Central
Posts: 419
Likes: 346
|
Post by david42 on Feb 21, 2015 10:28:22 GMT
|
|
