Help

[shakespeare62]

I have no idea what day ot got here as i cannot think back a year ago plus the envelope was not date stamped, but going by the above proving that is not important now anyway as theyadmit that the first was not correct and gave a silly excuse why.

 

Yes the DN failings are in my defence hence why i got another WS from them above.

 

PF

 

If it is a clerical error - then this must have been produced from database i.e. it is a "reconstruction" of an alleged Default Notice and NOT an exact copy. How else did they create it ?

 

I believe there should be an audit trail for Financial Transactions. Everyone who has access to sensitive information in a financial institution, has to have a log on id and password etc (I'm sure this is an FSA requirement). Data Entries and amendments will need to be logged on record.

 

There should be an audit trail - with the username, date , time of entry for this Default Notice. Otherwise it would be open to massive compromise anyone could change the data and it would be open to corruption, fraud etc.

 

They should therefore produce the audit trail for the day the two alleged default notices were issued - and the witness should be available for cross - examination.

 

If they can't produce the above - how can they guarantee their data is secure ? That it hasn't been tampered with ? We know what they are up to of course. It's important when you are challenging the veracity of their evidence.

[shakespeare62]

In fact, they would have to rope more and more people into this 'fraud'. The DBA (Database Administrator would have to give a witness statement that the record printout retrieved is accurate, then the Data Entry Clerk(s) who made the original entry would need to do the same). The more people involved the more potential points of 'failure' under cross examination.

 

I mean ultimately an audit of their IT system - could mean Game Over for MBNA and their DBA.

Edited April 16, 2009 by shakespeare62

[shakespeare62]

Also what are their procedures for creating a Default Notice ? I bet you it is computer program accessed via some sort of menu. Programs are consistent. They access a persons data, calculate a standard timescale on the calendar and produce consistent results time after time.

 

Operator intervention would be minimal. They wouldn't get the option to choose seven or 14 days once the Regs were in force. In practice the function would produce a standard output when selected. I don't buy MBNA's assertion at one point in the day it calculates the Default Notice Period one way, then a different way later in the day. This stinks.

 

What about all their other default notices issued for the same period - are they all different too ? I bet you they are not. Would they be williing to produce certified screen prints of their menu options for Default Notices ?

Edited April 16, 2009 by shakespeare62

[shakespeare62]

tidied up - removed duplicate post above

Edited April 16, 2009 by shakespeare62

[shakespeare62]

Remember we're not talking about some minion counting out 14 days on their fingers and selecting a value from a drop down calendar list - this would be a standard process - 'once click'

[shakespeare62]

Thanks guys. Pompey sorry to hear about your dad. You’re also recovering from hospital and can surely do without having to deal with a ‘bent organisation’ on top of everything.

 

I would like to outline a couple more things if I may (see my next 2 posts below)

Edited April 17, 2009 by shakespeare62

[shakespeare62]

Firstly A brief overview of how their IT System would handle Default Notice production :-

 

A large Bank / Financial institution would have a list of account numbers to be defaulted each day. A software process (likely to be menu driven), would allow the Data Entry Clerk to request a Default Notice to be issued for each account. Each selected account is ‘flagged’ on the database in some way to indicate the action required.

 

An overnight process is then run (because more computer resources are ‘free’ at the end of the day), to access the database and print out Default Notices for each selected account. The print outs are directed to a networked printer at some office / mail fulfilment branch. The next morning the branch employees stuff the default notices along with other mail in matching envelopes and place them in mailbags for collection at a given time in the day.

 

What the Data Entry Clerk doesn’t do - is to print out the Default Notice himself, run round to the printer, put the notice in an envelope and post it (A DCA might - but not a big institution).

Edited April 17, 2009 by shakespeare62
tidied line spacing

[shakespeare62]

With the above in mind, a good line of cross examination can be pursued e.g. Why would the Clerk issue a Default notice twice on the same day ? What made him aware that the first Default Notice was invalid – did he see a printout ? (you can cross check answers against their printing procedures and the audit trail etc.) Did he view the amended record on screen ? Does the Menu Application allow this ? If it does – why didn’t he cancel the first request before issuing a second ? Did the Application allow him to change the notice period ? (unlikely). When was he first aware that the notice period should allow time for postage ? Was this company policy ? If not did he inform anyone ? Did the company continue to send Default Notices which did not allow time for service ? Did he amend all further Default Notices he requested ? Was yours the only Default Notice he changed ? Could this be confirmed by an audit trail of all Default Notices he issued ?

 

I believe there is good scope for throwing doubt on the authenticity of their evidence. They also run a risk that outsiders e.g. IT contractors have worked at MBNA offices in Chester on projects and may be familiar with their systems. So discrepancies given in Court could quickly come to light.

 

The obvious conclusion is that following your Defence, they are attempting to redeem a defective Notice by issuing a 'fake one'. This is ‘fraudulent’.

 

A default notice would normally only be re-issued by a creditor in circumstances where the arrears were settled within the original Default Notice period, and a debtor subsequently defaulted at a later date. Twice in one day is “Ball Hooks”.

Edited April 17, 2009 by shakespeare62

[shakespeare62]

Good luck for today PF

[shakespeare62]

Could the prospective credit agreement be in breach of s59 of the CCA 1974 ? (I can't see the details on the thumbnail agreements u've posted)

 

Here's some thought provoking snippets from a successful defence on prospective agreements used by PaulWalton (He WON) :-

 

[begin quote]

2 On the 19th May 2005, the Defendant signed an Application Form for a credit card facility to be provided by Claimant. (Exhibit 1)

 

3 Provision of this credit facility was dependant upon a satisfactory credit record being obtained by the Claimant from one or more Credit Reference Agencies, and upon other lending decision criteria. The Application Form was therefore a pre-contractual agreement to enter into a prospective full-regulated credit agreement with the Claimant in the event that the Defendant’s application was successful.

 

4 The Application Form contained a clause, which included the following statement -

'Please issue me with an additional Barclaycard for use on the account(s) to which this application relates. I accept to be bound by the Barclaycard Conditions of use'. As such, the application purports to bind the Defendant to the terms and conditions of any prospective credit agreement with the Claimant.

 

5 Section 59 (1) of the Consumer Credit Act 1974 states that 'an agreement is void if, and to the extent that, it purports to bind a person to enter as debtor or hirer into a prospective regulated agreement.’ The Defendant therefore contends that this pre-contractual document, not being a regulated credit agreement in itself, and insofar as it purports to bind the Defendant to the terms of an actual prospective regulated credit agreement, is void and of no effect.

 

[end quote]