Interest transfer loop

Thanks for raising, I'll look into it.

warn - only FIVE. SEVEN transfers in my account. Second month in a row that Assetz have messed up. Confidence in Assetz waning. 

Rookies. My 30DAA withdrew £50 interest 20 times. 

I'm seeing a freeze on QAA, 40-odd quid not invested from a combination of cash account and QAA direct thus generating similar difference between the totals of investment v lent. Don't think I've seen that in a very long time.

I shoved all of it into QAA only with the same result. 

Also I have my qaa set to withdraw repayments and interest but it's not done it this month and left the interest in the qaa from what I can see


1st Mar 2018 at 05:10 Investment into qaa direct from Quick Access Account -£27.53
1st Mar 2018 at 03:30 Interest payment for Quick Access Account for month 2018-02 @ 3.75% per annum £27.53

Worked fine in Feb from what I can see


1st Feb 2018 at 00:50 Inter account transfer to cash account > -£0.01
1st Feb 2018 at 00:30 Interest payment for Quick Access Account for month 2018-01 @ 3.75% per annum < £0.01

I may just be misreading the transactions.

WRT OP, the 4 extra transfers were reversed (in one lump sum) at 16:50. Thank you, chris and cohorts. Yet again, the IT superbeings work their magic, and we're back in the best of all possible worlds.

Yes, it's been a long day and I'm a little light-headed.

Explanation's actually quite complex.  A few weeks ago we switched to asynchronous updating of account balances after certain transactions, so for a loan repayment the loan account balance would be reduced making sure funds were there, but each lender account would have transactions written but not added to their balances.  That minimised database locks to only a few instead of needing to lock thousands of lender accounts at a time, reducing the chances of deadlocks and other performance issues from occurring.  A separate process then went through updating each account balance one at a time.  Repayments were getting difficult enough to process that we needed the performance boost.

This had a knock on effect of making withdrawals harder to process, as if they're processed as the interest transaction is credited then the account balance would no longer reflect that amount being credited so the funds would "be there" for the withdrawal to clear.  We thought about processing them asynchronously but then you have race conditions and other issues to deal with so instead allowed metadata to be added to the interest payments that would cause a withdrawal to be triggered when the separate background process went through and settled each transaction.

This has been working fine for normal repayments but there was a bug in the code for the access account repayments whereby the meta data wasn't being correctly reset / cleared when inserting each new interest payment into the database.  This caused multiple transactions for different lenders to include the last withdrawal requests.  So if a lender withdrew some interest and then four others had repayments before another lender had a withdrawal request then that first lender would have had their withdrawal request submitted four times.

There was never any danger of money moving between lender accounts as we use a template system for all financial transactions which limits where and how money can move to predefined patterns.  And there was nothing the reconciliation system could detect as all the balances were correct in all the accounts, and funds hadn't been created or destroyed, it was just that the withdraw requests had been accidentally processed multiple times. 

A code fix has been deployed and tested, the erroneous withdrawals corrected, and lender support desk briefed.