Frequently Answered Questions

CAIS is our shared database of consumer credit information. CAIS members – organisations who give consumer credit – share their consumers’ credit performance data with us. In return, they benefit from access to the rest of the CAIS database, to the same level as the data they contribute. They can then use this data to improve decision making when consumers apply for credit or other financial services.

Membership is available to companies who give consumer credit or lend to consumers. Members must also:

• be a registered lender holding a Consumer Credit Licence – unless they’re in the TV rental and utilities sectors, where technically no credit is provided
• be registered under the Data Protection Act
• grant a credit facility over a minimum period of months – so those offering 30 days’ trade terms or cash on delivery would be excluded
• have their customers’ consent to search and supply data
• be able to supply complete and accurate data files every month

CAIS membership is available at either ‘default’ or ‘full’ data levels and the member will be entitled to retrieve the same level of data in return. Standard full subscribers provide monthly data on all accounts – positive, delinquent and default. Default-only subscribers provide monthly data on all accounts that are in default.

If you’d like to join CAIS, the first step is to contact your Experian account manager. They’ll confirm whether your business is eligible and provide you with the relevant documents, including copies of the CAIS File Layout Specification, the Principles of Reciprocity and the Principles for the Reporting of Arrears, Arrangements and Defaults at Credit Reference Agencies.

In return the account manager will need copies of credit application forms for Experian to verify that the consent and notification clauses are suitably worded, as required by the Data Protection Act 1998 or, from May 2018, the GDPR (recommended wordings for the clauses may be found on the Experian website under Compliance). You’ll also need to produce confirmation of a consumer credit license and Data Protection registration.

Before becoming a member, you’ll need to compile a test file of data to ensure the data is formatted and submitted correctly and is of acceptable quality. As you’re preparing the test file, you’ll be asked to sign the CAIS agreement and the CAIS control team will allocate a unique source code to identify the portfolio. Once the test data is approved you’ll be granted access to the CAIS database.

Once accepted to CAIS, your portfolio will be held on our database and identified by the source code, which should be included in the header record of each update. CAIS members are obliged to supply updated to their data each month. Each monthly update is validated before it is loaded to the database, building up a clear picture of each customer with the latest balance information and, in the case of full data, accumulating a history of payment performance.

To ensure that CAIS reporting is fair and accurate, as required under the Data Protection Act 1998 (superseded by the GDPR from May 2018), it is essential that each month’s submission is timely, contains a complete file, is an accurate reflection of each customer, and is consistent with the data reported in previous months.

New members gain access to CAIS data on signing the contract and must load their first batch of data within three months. They also agree to follow a number of specific rules – for example, they must provide data files every month and make sure the data meets our quality requirements.

Timing of extracts
The first CAIS extract should be taken at a time when the data will reflect an up to date picture of the accounts most accurately. Future updates will then be expected at the same point in subsequent months.

CAIS membership is governed by the Principles of Reciprocity, administered by the Steering Committee on Reciprocity (SCOR). These principles provide a framework of regulation covering the supply and use of credit account data to credit reference agencies and have been endorsed by all of the appropriate credit industry trade associations.

Members also follow the Principles for the Reporting of Arrears, Arrangements and Defaults at Credit Reference Agencies – industry guidance issued to standardise the way different sectors report data.

We’ll provide copies of both documents when you become a CAIS member.

Under the Data Protection Act 1998 (superseded by the GDPR from May 2018) and the Consumer Credit Act 1974 (CCA) consumers have the right to quickly access the data held on their credit files by credit reference agencies. Under section 159 of the CCA, they also have specific statutory rights to challenge entries they feel are inaccurate. These rights ensure that a necessary balance is maintained between the interests of lenders and the rights of individuals.

If a consumer chooses to challenge a credit file entry with Experian under section 159 of the CCA, we’re required to provide a response to the consumer within 28 days, letting them know whether the entry has been deleted or amended, or whether no action has been taken.

As the vast majority of disputes relate to data provided by lenders, we can only take the relevant action and provide a response if we’ve investigated the record with the relevant lender and been given the necessary information. If the lender does not make a timely response we have to suppress the record in question, even though it may subsequently prove to be accurate.

Upholding consumer rights therefore relies heavily on the cooperation of lenders. In order to ensure that (i) the consumer receives a response within the statutory 28-day period and (ii) correct entries are not supressed from the credit file, we require lenders to respond to us within 14 days of receipt.

Our Data Query Console (DQC) aims to make this process as simple and efficient as possible. The DQC is an easy-to-use, web-based system that will show all queries outstanding and all archived queries that have already been responded to. When clients complete a query, this will be sent back to Experian and removed from the outstanding queries list instantly. Further information on the DQC will be provided when you become a CAIS member.

If an update cannot be supplied on the entire portfolio for one particular month, on loading the next month’s data, a question mark (?) will be inserted on each affected record representing the missing month’s status.

If an update cannot be supplied on an individual account for one month, on loading the next month’s data, a question mark (?) will be inserted on each affected record representing the missing month’s status.

A file of records will contain three types of record, all of which must be 530 bytes in length:

1. One header record
2. All the customer account records
3. One trailer record

Whether you’re sending test or live data, each file submitted to Experian must contain these three record types in that order. All files must also be complete and consistent. Where files for various portfolios (such as subsidiaries) are drawn from different locations or systems, these should be treated as separate sources, with each having their own identifying source code and update process.

When a file is submitted at full data-sharing level, every month it must contain any new accounts opened since the last extract, together with updates to records previously submitted to CAIS. It must also contain any accounts that have settled (or closed) since the previous update, for example account that are fully repaid. Any account that has moved into default should also be reported with the valid default details where appropriate. Any subsequent changes to the default, such as changes in the current balance, should also be reported.

Where the file is submitted at a default-only level, every month it must contain any new defaults since the last extract, together with any updates to defaults previously reported into CAIS.

The following is the technical overview for data produced in the CAIS2007 file format for submission to Experian. CAIS2007 is the latest format and replaces the CAIS2006, CAIS2004, CAISPlus, Year 2000 and pre-Year 2000 versions.

When preparing data files, please also refer to any other relevant documents such as the latest version of the Principles of Reciprocity, Principles for the Reporting of Arrears, Arrangements and defaults at Credit Reference Agencies, plus any service-level agreement you may have in place with Experian.   

Header record

The first record on the file must be a header record as follows:

Account records

After the header record all of the individual customers’ account records must be in the following layout:

Trailer record

The last record on the file must be a trailer record as follows:

Each of the fields on CAIS records has a set of requirements and constraints. Any errors may result in either data becoming corrupted or an entire file being rejected, so please take time to ensure each field is correctly filled.

Header record

1. Header identifier

   Starting byte:	1
   Ending byte:	20
   Character type:	Alpha
   Example:	‘                          HEADER’
   Position:	Right justified with leading blanks

   • Only alpha values are accepted in this field. Any blanks or non-alpha values will prevent the entire file from updating.
   • Must be 14 blanks followed by the word HEADER in capitals.
      

2. Source code number

   Starting byte:	21
   Ending byte:	23
   Character type:	Numeric
   Example	‘012’
   Position:	Right justified, filled with leading zero where appropriate

   • The source code is a three-digit number, which will uniquely identify a member's portfolio for its duration on CAIS.
   • New members joining CAIS will be allocated a CAIS source code once the compliance sign-off process is complete.
      

3. Date of creation

   Starting byte:	24
   Ending byte:	31
   Character type:	Numeric
   Example:	‘24052010’
   Position:	Right justified, filled with leading zeros where appropriate

   • Only numeric values are accepted in this field. Any blanks or non-alpha values will prevent the entire file from updating.
   • The date format must be DDMMCCYY.
   • The creation date should reflect primarily when the extract is produced. Where an extract for a prior month is being recreated, this date should reflect the period to which the data relates.
   • All files must have a valid date.
      

4. Company / portfolio name

   Starting byte:	32
   Ending byte:	61
   Character type:	Alphanumeric
   Example:	‘ABC Bank Plc                               ’
   Position:	Left justified with following blanks

   • The contents of this field should be sufficient to identify both the company and the particular portfolio.
      

5. Filler

   Starting byte:	62
   Ending byte:	81
   Character type:	Blanks

   • The entire contents of this field should be blanks.
      

6. CAIS version indicator

   Starting byte:	82
   Ending byte:	89
   Character type:	Alphanumeric
   Example:	CAIS2007

   • The word CAIS should be supplied in capitals.
   • Only ‘CAIS2004’, ‘CAIS2006’ and ‘CAIS2007’ are currently valid in this field, with anything else reported as an error.
   • The contents of this field should fill the 8 bytes available.
      

7. Overdraft reporting cut-off

   Starting byte:	90
   Ending byte:	95
   Character type:	Numeric
   Example:	001250
   Position:	Right justified, filled with leading zeros where appropriate

   • This field is only applicable for portfolios containing current account submissions.
   • This field indicates where a client has chosen not to provide debt balances up to the cut-off balance indicated in the field for their current accounts records, at status code zero (only). All debt balances up to this value will have been provided as zero for accounts at status code zero. The agreement to supply data in this way and the value that can be used will have been pre-agreed through SCOR. Please confirm before using this field with a value other than zeros.
   • This field is to differentiate between portfolios submitting all debt balances available and those that are not. If you are providing all balances available the field should contain only zeros.
   • Only numeric values are accepted in this field. Blanks and non-numeric values will prevent the entire file from updating.
   • Only full pounds should be entered, for example: £2,000 = 002000. Any pence should be dropped, so £2,000.59 would be reported as £2,000.
      

8. Card behavioural sharing flag

   Starting byte:	96
   Ending byte:	96
   Character type:	Alpha
   Example:	Y

   • This field is only applicable for portfolios containing card behavioural sharing data.
   • A Y in this field indicates a client that has chosen to provide any of the card behavioural sharing data fields.
   • Only Y or blank are accepted in this field – any other values will prevent the entire file from updating.
      

9. Filler

   Starting byte:	97
   Ending byte:	530
   Character type:	Blanks

   • The entire contents of this field should always be blanks.

Customer account records

1. Account number

   Starting byte:	1
   Ending byte:	20
   Character type:	Alphanumeric
   Example:	12345B6789B
   Position:	Left justified with following blanks where appropriate

   • Alphanumeric values including blanks are accepted in this field; however, the first character must be an alphanumeric and not a blank.
   • This field must be unique, since the exact contents are used as a key field for matching records during each monthly update. If more than one record on the monthly update is submitted with the same account number, the first record will be loaded and all subsequent records will be dropped.
   • The CAIS account number must be contained within the first 19 bytes.
   • The 20th byte must be blank when not being used to indicate a joint account. For data protection reasons, CAIS cannot accept one record containing two or more account holders and so joint account holders must be submitted as separate records. To avoid duplicate account numbers in this situation, enter a '1' in the 20th byte of the account number for the first holder and a '2' in the 20th byte of the second holder etc. Once allocated this joint account suffix must remain fixed to each party to the agreement, even where the agreement is later transferred into one name only or another party joins. For joint records the first 19 bytes of the account number should be the same across all parties to the account. A unique number per party is maintained by the use of the joint account indicator as detailed above.
   • Each account number should, wherever possible, remain precisely the same once allocated. Where any part of an account number is changed, for example; re-structured account numbers, lost and stolen credit cards or inter-branch transfers, the new account number must be supplied in the `New account number` field. In all subsequent months the new account number is then reported in this field. If you need to change any part of the CAIS account numbers that you have previously provided and are unable to use the ‘new account number’ field, contact Experian’s CAIS control department in advance of the change. System work may be required on your existing CAIS portfolio in advance of you making any changes and this work may be chargeable.
   • The CAIS files retain records for six years after default or closure. If account numbers are to be re-used within this six-year period each account number must be made unique by the addition of a key (such as the start date of the account) within the account number, for example, ‘12345B6789B 07/93’.
      

2. Account types

   Starting byte:	21
   Ending byte:	22
   Character type:	Numeric
   Example:	02
   Position:	Right justified, filled with leading zero where appropriate

   • Only numeric values are accepted in this field. Blanks and non-numeric values will prevent the entire file from updating.
   • Account types 52, 63, 65, 66, 67 and 68 are not currently available for CAIS submissions. For a full list of valid account types, see What are the different CAIS account types?
      

3. Start date

   Starting byte:	23
   Ending byte:	30
   Character type:	Numeric
   Example:	03071999
   Position:	Right justified, filled with leading zeros where appropriate

   • Only numeric values are accepted in this field. Blanks and non-numeric values will prevent the entire file from updating.
   • The date format must be DDMMCCYY.
   • The start date must always pre-date any close date.
   • In most cases the start date should be the date of the agreement but where the debt does not become due until a future point or action, the date the credit is drawn down may be more appropriate.
   • All accounts must have a valid date. Anything else will be reported as an error.
   • The only way to amend a start date that has been supplied in error is by making a manual amendment through the CAIS online amendments system.
      

4. Close date

   Starting byte:	31
   Ending byte:	38
   Character type:	Numeric
   Example:	30072000
   Position:	Right justified, filled with leading zeros where appropriate

   • Only numeric values are accepted in this field. Blanks and non-numeric values will prevent the entire file from updating.
   • The date format must be DDMMCCYY.
   • An open and active account must contain `00000000’ in this field.
   • The close date must always post-date the start date.
   • The presence of a valid date in this field will represent either:
      

5. a) The date of settlement for records at status U, 0, 1, 2, 3, 4, 5 or 6.

   b) The date of default for records at status 8.

   • Where the CAIS status is 8, (default) this field must contain an accurate date of default, meaning the date on which the decision to default became effective. Where a notice of intention to file a default has been served on the borrower, the default should date from the day the notice becomes effective. For further information please refer to the Principles for the reporting of Arrears, Arrangements and Defaults at Credit Reference Agencies
   • All records are automatically dropped from the CAIS database six years after the close date and, for this reason, CAIS members must retain any close date for as long as the account is held on a customer database. This will allow you to avoid accidentally resubmitting closed or defaulted accounts after the six-year period.
   • You must continue to updates active records until you have submitted a valid and accurate close date. By not reporting an open account it will result in the record being displayed as active but reflecting an increasingly out of date position. Inactive or dormant accounts should be submitted as closed and if subsequently re-opened the record can be resubmitted with a close date of '00000000', making the record active once more. During an update which includes a re-activation of an account, the update the letter 'D' (dormant) will be entered automatically into the status code field to highlight any months for which the account was closed.
   • The only way to amend a close date that has been supplied in error is by making a manual amendment through the CAIS online amendments system.
      

6. Monthly payment

   Starting byte:	39
   Ending byte:	44
   Character type:	Numeric
   Example:	000200
   Position:	Right justified, filled with leading zeros where appropriate

   • Only numeric values are accepted in this field. Blanks and non-numeric values will prevent the entire file from updating.
   • Only full pounds should be entered, for example: £200 = 000200. Any pence should be dropped, so £2,000.59 would be reported as £2,000.
   • For account types 01, 02, 03, 04, 07, 08, 16, 17, 19, 20, 21, 22, 23, 25, 27, 29, 30, 31, 32, 33, 34, 35, 39, 40, 41, 42, 43, 45, 46, 47, 48, 49, 50, 51, 58, 60, 61, 62, 64, 69 and 70 this field should contain the normal monthly payment, where applicable to your product. For all other account types enter zeros.
   • Where the frequency is other than monthly the payment should be calculated to produce a monthly amount. See What home credit accounts data should be supplied?
      

7. Repayment period

   Starting byte:	45
   Ending byte:	47
   Character type:	Numeric
   Example:	048
   Position:	Right justified, filled with leading zeros where appropriate

   • Only numeric values are accepted in this field. Blanks and non-numeric values will prevent the entire file from updating.
   • For account types: 01, 02, 03, 16, 17, 19, 20, 22, 23, 25, 27, 29, 30, 31, 32, 33, 34, 35, 45, 46, 47, 48, 60, 61, 62, and 69this field should contain the repayment period as the number of months applicable to the agreement. This should only be supplied where a repayment period is applicable to your product. For all other account types enter zeros.
   • This field should always reflect the full term of the agreement and not the number of months remaining.
   • If an agreement is extended the revised repayment period should be submitted on the following monthly extract.
      

8. Current balance

   Starting byte:	48
   Ending byte:	54
   Character type:	Numeric
   Example:	0003600
   Position:	Right justified, fill with leading zeros where appropriate

   • Only numeric values are accepted in this field. Blanks and non-numeric values will prevent the entire file from updating.
   • Only full pounds should be entered, for example: £3,600 = 0003600. Any pence should be dropped, so £3,600.59 would be reported as 0003600.
   • This field should contain the total outstanding balance whatever the status code of the record. Exceptions to this are account type 07 Rental (TV, Brown and White goods), 64 Other Rental, 22 Finance Lease and 23 Operating Lease, where a balance is not always applicable to the type of credit when the account is up to date (status code 0 or U). If the account falls into arrears then a balance should be provided to reflect the arrears position.
   • Where the status is other than 8 and the close date field contains a date (meaning the account has been settled) the current balance must be set to zero, regardless of any credit or debit balances remaining on the client accounting ledger. CAIS records must not be settled with an outstanding balance.
   • Where the status code is 8 (default) the current balance must be updated on CAIS each month, as the amount outstanding changes.
   • Where the status is 8 (default) submitting a current balance of zero will result in the CAIS record being displayed as ‘satisfied’.
   • Where the status is 8 (default) the current balance must not be submitted as a credit balance. If the client accounting ledger correctly contains a credit balance (perhaps through an overpayment) the current balance must still be reported as zero.
   • Where on a status 8 (default) the full balance is not to be recovered the current balance should be reported as zero and the record satisfied. For example, this might occur where a short settlement has been agreed, the debt is included in a discharged bankruptcy or in a successfully completed voluntary arrangement, or where an asset has been repossessed and the balance is not being pursued. In these circumstances the partial settlement flag should be set.
      

9. Credit balance indicator

   Starting byte:	55
   Ending byte:	55
   Character type:	Alpha
   Example:	‘ ’ if in debit, ‘-’ if in credit

   • Where the account is in credit, this field should contain the credit balance indicator, otherwise it should contain a blank. The exception to this is current accounts where credit balances should not be supplied.
   • Credit balance in this context does mean that the customer is owed a repayment from the lender and does not mean being in advance of contracted terms.
   • By definition credit balances are not allowed on status 8 (default) records.
      

10. Account status codes

    Starting byte:	56
    Ending byte:	56
    Character type:	Alphanumeric
    Example:	0

    • The status code is a monthly indication of the payment performance of the account.
    • For a full list of acceptable status codes, see How should the CAIS account status codes be used? The presence of any characters (including a blank) other than one of the acceptable status codes will prevent the entire file from being updated.
    • All active records should be provided on a monthly basis even if there have not been any transactions on the account.
    • Only records with a status code of 8 are expected on default portfolios, while full-data files are expected to report arrears up to a minimum of status code 3 before reporting as a default status code 8.
    • Once an arrangement has been agreed, the record must not be reported as defaulted unless the borrower has failed to maintain the revised terms. This should not result in a default being filed any sooner than would have been the case had the arrangement not been agreed. For further details please refer to the Principles for the reporting of Arrears, Arrangements and Defaults at Credit Reference Agencies.
    • Once a record has been reported at a status code of 8, only a further record submitted at a status code of 8 can update it. To submit any other status code will result in the update for that record being rejected.
    • In allocating a status code 1 to indicate an account moving into arrears it is advisable to include a 7- to 14-day period of grace to allow for a payment which has been unusually delayed.
    • The only way to amend previous monthly status codes or removing a status code 8 allocated in error is by making a manual amendment through the CAIS online amendments system.
       

11. Special instruction indicator

    Starting byte:	57
    Ending byte:	57
    Character type:	Alpha
    Example:	L

    • The only acceptable contents for this field are D, A, L or a blank. Where used the flags should be entered in capitals, otherwise this field should contain a blank.
    • To delete a record held on CAIS enter a D in this field. This function is only to be used in exceptional circumstances to remove accounts registered in error.
    • Where name and address is being changed on a status 8 (default) the new details should be included on the record and an A entered in this field.
    • In some cases it may be necessary to amend details to re-direct mail to an internal address to avoid it being sent to the customer (for example, if the consumer is deceased or gone away). To prevent the corruption of an accurate name and address on the CAIS database, enter an L in this field. The L flag must be given for as long as the internal details are present on your database. The L flag should not be used for accounts that are not already present on the CAIS database.
       

12. Experian block

    Starting byte:	58
    Ending byte:	207
    Character type:	Blanks

    • This field may be used for your own data purposes, for example a scoring reference number. However, unless you ask Experian to undertake additional work, nothing in this field is retained after the monthly update.
    • Any part of this field not being used for your own data purposes should be filled with blanks.
       

13. Payment amount

    Starting byte:	208
    Ending byte:	213
    Character type:	Numeric
    Example:	000360
    Position:	Right justified, filled with leading zeros where appropriate

    • This field is for use on card products only (account type 05). For all other product types the field should contain zeros.
    • Only numeric values are accepted in this field. Blanks and non-numeric values will prevent the entire file from updating.
    • Only full pounds should be entered, for example: £3,600 = 0003600. Any pence should be dropped, so £3,600.59 would be reported as 0003600.
    • For account type 05 this field should contain the net value of payments credited in the previous billing period. This is true payments only (meaning it should not include non-payment credits such as refunds), credited to the account in the previous billing period net of any reversals (for example, a bounced cheque, direct debit or standing order). It may include multiple payments received in the same period.
    • Where no payment has been made zeros should be provided.
       

14. Credit payment indicator

    Starting byte:	214
    Ending byte:	214
    Character type:	Alpha
    Example:	Blank if in debit, ‘-’ if in credit

    • This field is for use on card products only (account type 05). For all other product types the field should contain a blank.
    • This field should be populated only if the value of net payments in the above field is in credit.
    • Only blank or ‘-’ are accepted in this field. Other values will prevent the entire file from updating.
    • This field reflects true payments net of any payment reversals (for example: a bounced cheque, direct debit or standing order) as stated. Where the total of payment reversals is more than the total of payments made in that cycle, the reported payment amount will be negative.
       

15. Previous statement balance

    Starting byte:	215
    Ending byte:	220
    Character type:	Numeric
    Example:	001234
    Position:	Right justified, filled with leading zeros where appropriate

    • This field is for use on card products only (account type 05). For all other product types the field should contain zeros.
    • Only numeric values are accepted in this field. Blanks and non-numeric values will prevent the entire file from updating.
    • Only full pounds should be entered, for example: £1,234 = 001234. Any pence should be dropped, £1,234.59 would be reported as 001234.
    • For account type 05 this field should be populated with the balance at the statement date on the previous, not current, statement, relating to the requested payment amount. This is to be reported in addition to the current balance field.
       

16. Previous statement balance indicator

    Starting byte:	221
    Ending byte:	221
    Character type:	Alpha
    Example:	Blank if in debit, ‘-’ if in credit

    • This field is for use on card products only (account type 05). For all other product types the field should contain zeros.
    • This field should be populated if the previous statement balance field (above) is in credit.
    • Only blank or ‘-’ are accepted in this field. Other values will prevent the entire file from updating.
       

17. Number of cash advances

    Starting byte:	222
    Ending byte:	223
    Character type:	Numeric
    Example:	02
    Position:	Right justified, filled with leading zeros where appropriate

    • This field is for use on credit card products only (account type 05). For all other product types the field should contain zeros.
    • This field should be populated with the number of cash advances that were made in the previous billing period. This includes UK ATM transactions, foreign ATM transactions and over-the-counter (OTC) cash, for example bureau de change. It should not include retail cash back or quasi cash transactions, gambling cash advances and any fees or charges.
    • If there have been more than 99 individual advances within the month the value should be provided as 99. Only numeric values are accepted in this field. Blanks and non-numeric values will prevent the entire file from updating.
       

18. Value of cash advances

    Starting byte:	224
    Ending byte:	229
    Character type:	Numeric
    Example:	000500
    Position:	Right justified, filled with leading zeros where appropriate

    • This field is for use on card products only (account type 05). For all other product types the field should contain zeros.
    • This field should be populated with the value of cash advances that were made in the previous billing period. This includes UK ATM transactions, foreign ATM transactions and over-the-counter (OTC) cash, for example bureau de change. It should not include retail cash back or quasi cash transactions, gambling cash advances and any fees or charges. It is best practice not to include any cash advances fee(s) in the field’s value that, if they are recorded, do not add to the field for the number of cash advance’s count.
    • Only numeric values are accepted in this field. Blanks and non-numeric values will prevent the entire file from updating.
    • Only full pounds should be entered e.g. £500 = 000500, any pence should be dropped. For example £5,00.59 would be reported as 000500.
    • Only full pounds should be entered, for example: £500 = 000500. Any pence should be dropped, so £500.59 would be reported as £000500.
       

19. Payment code

    Starting byte:	230
    Ending byte:	230
    Character type:	Alpha
    Example:	M

    • This field is for use on card products only (account type 05). For all other product types the field should contain zeros.
    • This field should be set with M if only the minimum payment requested on the previous statement has been made.
    • Only M or blank are accepted in this field. Any other values will prevent the entire file from updating.
       

20. Promotion activity flag

    Starting byte:	231
    Ending byte:	231
    Character type:	Alpha
    Example:	Y

    • This field is for use on card products only (account type 05). For all other product types the field should contain zeros.
    • This field should be used to indicate any form of current promotional activity on the account and where the customer is actually benefiting from the promotion.
    • This may reflect new or ‘life of balance’ rates, whether purchase, balance transfers, credit card cheque, or other promotions.
    • Only Y, N or blank are accepted in this field. Any other values will prevent the entire file from updating.
       

21. Filler 1

    Starting byte:	232
    Ending byte:	262
    Character type:	Blanks

    • The entire contents of this field should always be blanks.
       

22. Transient association flag

    Starting byte:	263
    Ending byte:	263
    Character type:	Alpha
    Example:	T

    • To prevent a financial association being created from joint CAIS records, this field should be populated with a value of ‘T’.
    • For associations to be created automatically, a joint CAIS record is defined as two or more CAIS records, which contain the same 19 byte CAIS account number, balance and current status.
    • The flag should only be used on limited occasions, such as when individuals who could not be described as being members of a financial unit join together to purchase or rent a shared asset – for example, students renting a television or jointly purchasing a fridge.
    • In order to prevent an association being registered a flag may be supplied at search and during the life of the account. This facility will not be permitted for certain products, such as mortgages.
    • Only T or blank are accepted in this field. Any other values will prevent the entire file from updating.
    • If a transient association is not applicable then the field should contain a blank and associations will be created.
    • The flag should not be used with account types applicable to mortgages (specifically 03, 16, 25, 30, 31, 32, 33, 34, 35, 50 and 69)
    • The flag should only be supplied the first time a record is provided to CAIS.
       

23. Air-time retailer flag

    Starting byte:	264
    Ending byte:	264
    Character type:	Alpha
    Example:	L

    • This flag is for use only by air-time retailer members of the FCS subscribing to CAIS.
    • The only acceptable contents for this field are L, B, D or blank. Where used the flags should be entered in capitals, where the flags are not required this field should contain a blank.
    • Where the account is live enter the letter L.
    • Where the account is barred enter the letter B.
    • Where the account is disconnected enter the letter D.
    • All other companies should enter a blank in this field.
       

24. Flag setting

    Starting byte:	265
    Ending byte:	265
    Character type:	Alpha
    Example:	A

    • For the full list of acceptable flags and when they should be used, see How should the CAIS flags be used?
    • Only a flag setting or a blank can be used here, and using any other character will prevent the entire file from being updated.
    • Flag settings must be used in conjunction with the appropriate status codes.
    • The flags are listed in a hierarchical order. Where two or more flags are applicable at the same time, use the flag with the greater hierarchy.
       

25. Name and address

    Starting byte:	266
    Ending byte:	440
    Character type:	Alphanumeric
    Example:	Mr John W Brown Rose Cottage 5 Main Street Beeston Nottingham, Nottinghamshire NG8 1JD
    Position:	Left justified with following blanks

    The format of this field is as follows:

    
    Name 39 characters  

    Address line 1 32 characters

    Address line 2 32 characters

    Address line 3 32 characters

    Address line 4 32 characters

    Postcode 8 characters

    • The name line should include title, full forename, middle initial (where captured) and the surname. These are mandatory on all new records from 24 October 2001.
    • The postcode, which is mandatory, must always be in the last 8 bytes and must be eight characters in length.
    • Any unused sections of the address lines should be filled with blanks.
    • The name and address lines should contain no punctuation other than apostrophes or hyphens within a name (for example, ‘Patrick O’Neil’)
    • The address supplied on CAIS records must always represent the consumer’s actual residential address.
    • To confirm the acceptability of a format that is not as detailed above please contact the CAIS control team who will arrange for the data to be tested.
    • Once data has been loaded to the live environment, name and address formats must not be changed without first notifying Experian. Such changes have a lead time so that the project can be specified, the analyst time scheduled and the costs approved. Changes undertaken without prior notification will result in all addresses being rejected as errors and will prevent your file being updated.
    • To change an address on active or settled accounts the record may be submitted with the new details in place of the previous. To change the name and address on a status 8 (default) however, the A flag must also be present in the special instruction indicator field.
    • In some cases it may be necessary to amend details to re-direct mail to an internal address to avoid it being sent to the customer (for example, if the consumer is deceased or gone away). To prevent an accurate and valid address from becoming corrupted, enter an L in the special instruction indicator field. The L flag must be given for as long as the internal address is present on your database. The L flag should not be used for accounts that are not already present on the CAIS database.

26. Credit limit

    Starting byte:	441
    Ending byte:	447
    Character type:	Numeric
    Example:	0005000
    Position:	Rights justified, filled with leading zeros as appropriate

    • Only numeric values are accepted in this field. Blanks and non-numeric values will prevent the entire file from updating.
    • Only full pounds should be entered, for example: £5,000 = 005000. Any pence should be dropped, so £5,000.59 would be reported as £5,000.
    • For account types: 04, 05, 06, 08, 15, 18, 25, 27, 37, 38, 44, 53, 54, 55, 56, 57, 58, 59, 70 and 71 this field should contain the credit limit as notified to the customer, where applicable to your product. For all other account types enter zeros.
       

27. Date of birth

    Starting byte:	448
    Ending byte:	455
    Character type:	Numeric
    Example:	13051978
    Position:	Right justified, filled with leading zeros as appropriate

    • Only numeric values are accepted in this field. Blanks and non-numeric values will prevent entire file from updating.
    • This field is a mandatory requirement on all new records from 24 October 2001 and must contain the actual date of birth not the age of the customer. If the complete date of birth is not available, the whole field should be filled with zeros.
    • The date format must be DDMMCCYY.
    • Where the date of birth indicates the borrower is less than 18 years of age, please consider whether the data is incorrect or if the account has been opened in error.
    • Where the date of birth indicates a borrower less than 16 years of age the CAIS programs will automatically set this field to zeros.
    • If a date of birth has been set incorrectly it can be updated via the monthly update or via manual amendment. Any changes to this field on the monthly file will automatically be picked up, except where we hold a valid date and the monthly update contains zeros.
       

28. Filler 2

    Starting byte:	456
    Ending byte:	456
    Character type:	Blanks

    • The entire contents of this field should always be blanks.
       

29. Transferred to collection account flag

    Starting byte:	457
    Ending byte:	457
    Character type:	Alpha
    Example:	Y

    • The only acceptable contents for this field are Y or blank.
    • This field should be used where the record provided has been transferred to a collection account. This process is often referred to as consolidating debt.
    • Please ensure that the consolidated debt record is provided at the same time as the original record is indicated as transferred. This ensures debts are not duplicated or information on the current performance of an account is not missing.
    • Where a transferred to collection account flag is submitted the current balance should stand at zero and there must be a valid date in the close date field to indicate a transfer date, or a default date if the record is a default. Where there is no valid close date the flag will be dropped but the rest of the input record will be processed.
    • This field should not be used when a sold debt is transferred back to the original owner as a result of recourse on the sale. Accounts in this scenario would be deleted from the purchaser’s CAIS submission and reported only on the owner the account has been transferred back to.
       

30. Balance type

    Starting byte:	458
    Ending byte:	458
    Character type:	Alpha
    Example:	P

    • This flag is for use on current account products only (types 15, 25, 27, 33 and 71). For all other product types this field should contain a blank.
    • The only acceptable contents for this field are A, P or blank.
    • A indicates that the average balance in a month has been provided in the current balance field.
    • P indicates that the balance reflects the point in time when the CAIS update was taken.
       

31. Credit turnover

    Starting byte:	459
    Ending byte:	467
    Character type:	Numeric
    Example:	000012345
    Position:	Right justified, filled with leading zeros where appropriate

    • This flag is for use on current account products only (types 15, 25, 27, 33 and 71). For all other product types the field should contain zeros.
    • The contents of this field should be the value of all payments into the account during the last month. It should exclude any internal transfers from other accounts within the same organisation / group. Any credit transactions from a savings account into the current account within the month should also be excluded from this value.
    • Only numeric values are accepted in this field. Blanks and non-numeric values will prevent the entire file from updating.
    • Only full pounds should be entered, for example £2,000 = 000002000. Any pence should be dropped, so £2,000.59 would be reported as 000002000.
       

32. Primary account indicator

    Starting byte:	468
    Ending byte:	468
    Character type:	Alpha
    Example:	Y

    • This flag is for use with account types 15, 25, 26, 27, 33 and 71 only. For all other account types the field should contain a blank.
    • The only acceptable contents for this field are Y, N or blank.
    • Y indicates that you believe this record to be the customer’s primary current account. The fact that the customer’s regular income is being paid into the account should be used as an indication to set the primary flag.
    • If the customer only holds one current account then this should be indicated as primary only if the customer’s regular income is paid into the account. Any other records should be indicated with N in this field.
    • If the customer holds two or more current accounts then the account which receives the customer’s regular income should be indicated as primary. Any other records should be indicated with N in this field.
    • If customers are holding two separate joint accounts with each of the individuals’ regular income paid into separate accounts, both records should be indicated as primary.
       

33. Default satisfaction date

    Starting byte:	469
    Ending byte:	476
    Character type:	Numeric
    Example:	14092012
    Position:	Right justified, filled with leading zeros where appropriate

    • Only numeric values are accepted in this field. Blanks and non-numeric values will prevent the entire file from updating.
    • The date format must be DDMMCCYY.
    • This field is only applicable for default records (status code 8).
    • The default satisfaction date must always post-date the start date and default date.
    • An outstanding default or an active account must contain 00000000 in this field.
    • Where a satisfaction date is submitted the current balance field must be zero. Where the balance is not zero the date will be stored but the record will not be indicated as satisfied.
    • The only method of amending a satisfaction date that has been supplied in error is by making a manual amendment through the CAIS online amendments system.
    • Defaulted accounts that have been completed as ‘full and final settlement’ even if a lesser amount is accepted as final payment, the account should be marked as satisfied.
       

34. Transactions flag

    Starting byte:	477
    Ending byte:	477
    Character type:	Numeric
    Example:	1

    • This flag is for use on current account products only (types 15, 25, 27, 33 and 71). For all other product types the field should contain a blank.
    • The only acceptable contents for this field are 0, 1 or blank. Where used the flags should be numeric. Where the flag is not applicable this field should contain a blank.
    • This field is to indicate where cheques or direct debts from a current account have not been paid due to insufficient funds within the last month.
    • 0 indicates no unpaid transactions within the last month.
    • 1 indicates that transactions have been unpaid within the last month.
       

35. Filler 3

    Starting byte:	478
    Ending byte:	502
    Character type:	Blanks

    • The entire contents of this field should always be blanks.
       

36. Original default balance

    Starting byte:	503
    Ending byte:	509
    Character type:	Numeric
    Example:	0005000
    Position:	Right justified, filled with leading zeros where appropriate

    • This field should only be populated when the status is 8 (default). Where the status is other than 8 this field should be filled with zeros.
    • Only numeric values are accepted in this field. Blanks and non-numeric values will prevent the entire file from updating.
    • Only full pounds should be entered, for example £5,000 = 0005000. Any pence should be dropped, so £5,000.59 would be reported as 0005000.
    • This field should contain the total amount outstanding at the point when the default occurred. The current outstanding balance for a default record must always be supplied as the current balance in field 7 above.
    • Where the original default balance is zero, a default cannot be registered and the record will be rejected.
    • The original default balance cannot be submitted as a credit balance. Where this occurs, the record will be rejected.
    • Where an original default balance is submitted as less than £10, the CAIS record will be automatically set private. It is recommended that in these circumstances the CAIS record should be shown as settled at the previous status code.
    • The only method of amending an original default balance that has been allocated in error is by making a manual amendment through the CAIS online amendments system.
       

37. Payment frequency indicator

    Starting byte:	510
    Ending byte:	510
    Character type:	Alpha
    Example:	W

    • These indicators can be used in conjunction with any of the status codes.
    • If no flag is to be used this field should remain blank.
    • The contents of this field have no effect on the monthly payment field that must be calculated separately to arrive at a monthly amount.
       

38. New account number

    Starting byte:	511
    Ending byte:	530
    Character type:	Alphanumeric
    Example:	12345B6789B
    Position:	Left justified, with following blanks

    • This field should be used where the account number is being changed from that contained in the account number in field 1 above. The original account number that is already on CAIS must be submitted in field 1 with the new number entered in this field. Once the account number has been changed the new number must be reported for all future updates within field 1.
    • Alphanumeric values including blanks are accepted in this field. However, the first character must be an alphanumeric and not a blank.
    • All account numbers must be unique as the exact contents are used as a key field for matching records during each monthly update. If more than one record with the same account number is submitted on the same update, the first record will be loaded and all subsequent records will be dropped.
    • The new account number must not already exist on your CAIS portfolio as this will cause conflict between which account number requires updating. In this situation the new account number will be automatically removed to allow the monthly update to be processed. This will allow an update to the old account number and not update the new account number. As this could cause certain records to not be updated this approach should be avoided.
    • Where a record is supplied with an account number change and the new account number is provided on a separate record within the same monthly update, this will again cause conflict within the CAIS monthly update. In this situation the separate record containing an update to the same new account number provided as an account number change will be automatically removed to allow the monthly updates to be processed. This could cause certain records to not be updated with the most recent information and therefore should be avoided.
    • The account number must be contained within the first 19 bytes.
    • The 20th byte must be blank when not being used to indicate a joint account. For data protection reasons CAIS cannot accept one record containing two or more account holders, and so joint account holders must therefore be submitted as separate records. To avoid duplicate account numbers in this situation, enter a ‘1’ in the 20th byte of the account number for the first holder and a ‘2’ in the 20th byte of the second holder. Once allocated this joint-account suffix must remain fixed to each party to the agreement, even where the agreement is later transferred to one name only.
       

Trailer record

1. Trailer identifier

   Starting byte:	1
   Ending byte:	20
   Character type:	Numeric
   Example:	99999999999999999999

   • Only numeric values are accepted in this field. Blanks and non-numeric values will prevent the entire field from updating.
   • This field should be completely filled with the numeric 9.
      

2. Total number of records

   Starting byte:	21
   Ending byte:	28
   Character type:	Numeric
   Example:	01234567
   Position:	Right justified, with leading zeros where appropriate

   • Only numeric values are accepted in this field. Blanks and non-numeric values will prevent the entire field from updating.
   • This field should contain the total number of customer account records and must exclude the header and trailer records, for example 123,456 records = 00123456.
      

3. Filler

   Starting byte:	29
   Ending byte:	530
   Character type:	Blanks

   • The entire contents of this field should always be blanks.

Listed below are the fields that are required and whether or not they are mandatory for either a full or a default CAIS record. These requirements may change from time to time following amendments to the Principles of Reciprocity and mandatory fields are subject to change.

Flags should be used where they describe the current account relationship.

The hierarchy of CAIS flags is as follows. Where more than one applies the flag with the greatest hierarchy should be submitted. Where a flag currently exists it can only be replaced by one that’s higher up in the hierarchy. The only exception to this is gone away flags – see below.

1. Deceased (D)

   Where you receive evidence that an account holder is deceased (for example a death certificate, probate or letters of administration) you should set a D flag.

   • A deceased flag can only be input against a CAIS status U where the record already exists on CAIS with a status of 0, 1, 2, 3, 4, 5, 6, D or U.
   • A deceased flag can be input against a previously filed CAIS status 8 provided it is submitted with a status of 8.
   • Where a deceased flag is input with a status other than U or 8, the whole record will be rejected.
   • A deceased flag once set cannot be updated to a different flag. But it can be changed manually if it is discovered to be in error.
   • A deceased record is still expected to receive monthly updates until it is marked as settled.
      

2. Partial or no settlement (P)

   Where a partial settlement has been agreed or the debt has been discharged by bankruptcy, a P flag should be set.

   • A P flag may be used with any status code.
   • Where a P flag is submitted there must be a valid close date to indicate a settled or satisfied record and a zero current balance. Where there is no valid close date the flag will be dropped but the rest of the input record will be processed.
   • The P flag should be used in the following circumstances where the record is being marked with a zero balance and full payment has not been received. The record may in some cases also be marked as settled/satisfied but the debt was not fully paid and in some cases no payment was made at all:
     • The debt was included in an IVA which has been completed successfully.
     • The debt was included in a bankruptcy which has since been discharged.
     • A smaller amount has been agreed and accepted in full and final settlement, but this term has not been conveyed to the consumer
     • An asset has been repossessed and the outstanding balance is not to be pursued.
   • A record with the P flag is not expected to receive any further monthly updates. Further updates will be rejected unless the flag is removed manually.
      

3. Debt assigned (C)

   The debt-assigned (C) flag should be used where the rights to a debt have been assigned to a new owner who is not a member of CAIS and so will not be registering the debt on CAIS in their own name. The record remains in the original lender's name, shown as settled or satisfied, together with the debt-assigned flag to indicate that the record is closed due to its sale.

   • A C flag may be used with any status code.
   • Where the C flag is used, the current balance must be zero.
   • The close date field must contain a valid date of settlement or the original default date. Where there is no valid close date the flag will be dropped but the rest of the input record will be processed.
   • A record assigned to a new owner is not expected to receive any further monthly updates. Further updates will be rejected unless the flag is removed manually.
      

4. Debt sold to CAIS member (S)

   The debt-sold-to-CAIS-member (S) flag should be used where the rights to a debt have been assigned to a new owner that is already a CAIS member. In this case, the new owners will continue to supply the performance of the record via their own portfolio. The original record will remain on CAIS indicated as sold to CAIS member, shown as settled or satisfied together with this flag to indicate the record is closed due to its sale.

   • An S flag can be used with any status code.
   • Where the S flag is used, the current balance must be zero.
   • The closed date field must contain a valid date of settlement or the original default date provided for default records. Where there is no valid closed date the flag will be dropped but the rest of the input record will be processed.
   • A record assigned to a new owner is not expected to receive any further monthly updates. Further updates will be rejected unless the flag is removed manually.
      

5. Gone away (G)

   Where the address of the customer is no longer known and the account is falling into arrears, a G flag should be used together with the last known address.

   • A G flag does not necessarily indicate a defaulted account.
   • A G flag can only be registered if the account is in arrears. The CAIS status code accompanying the flag must be 1, 2, 3, 4, 5, 6, or 8.
   • If the status is 0, D or U the flag will be dropped but the rest of the input record will be processed.
   • A record input with a blank in the flag field which matches to a previously filed gone-away flag, will remove all reference to the gone-away flag from that record.
   • A gone-away record is still expected to receive monthly updates until the point at which it is marked as settled or is defaulted.
   • If a gone-away record is received with any other type of flag the record will be updated with the new flag an it will be assumed that the person is now located.
      

6. Recourse (R)

   Where an account is invoked with a recourse agreement (for example between a dealer and a lender), the record should be set with an R flag.

   • The date of recourse should be entered in the close date field.
   • A recourse flag can only be registered if the account is in arrears, so the CAIS status must be 1, 2, 3, 4, 5, 6, or 8.
   • If the status is 0, D or U then the flag will be dropped but the rest of the input record will be processed.
   • Once set, a recourse flag shouldn’t be updated to a different flag, but can be changed manually.
   • A recoursed record is not expected to receive any further monthly updates.
      

7. Voluntary terminations (V)

   A V flag can only be set if the record is a hire purchase agreement. It should be used: where a Consumer Credit Act Section 100 balance is outstanding and there is no arrangement (together with a CAIS status of 8); where a Section 100 balance is outstanding and there is an arrangement; and where a Section 100 balance has been met (in this case the account should be closed with the appropriate status code and a balance of zero).

   • The V flag must only be used with account types 01 or 20. Otherwise the flag will be dropped but the rest of the input record will be processed.
   • The flag can be set alongside any status code.
   • Where a voluntary termination is registered at any status code other than 8 or 0, the account is deemed to be an arrangement within a voluntary termination. Two monthly payments will be registered, the current monthly arrangement amount and the previous monthly payment (how much was being paid before the voluntary termination was enforced). If the two payment values are equal, the flag will be dropped but the rest of the input record will be processed.
      

8. Arrangement (A)

   Where a customer is given a payment arrangement, the arrears against the original contract should be shown using the status code, together with an A flag. Where the customer is making monthly payments (on certain CAIS account types only) the payment amount should also be given.

   • An A flag can only be set with statuses 0, 1, 2, 3, 4, 5, 6, D or U.
   • As a customer maintains the arrangement, the status code can be reduced back to 0 and the flag removed. With a more formal arrangement some revolving products may ‘re-age’ the account when the arrangement has been met satisfactorily, as reflected by the status code. In this case, an A flag should be set with a status code of 0 but without an end date, indicating that the arrangement is ongoing. If the customer breaches the terms of the arrangement the flag should be removed and debt should continue to age against the original contract.
   • Where the customer is making monthly payments, the payment amount is given in the usual monthly payment field. Two monthly payments will be shown on the CAIS record during a credit search – the current monthly arrangement amount and the original contracted monthly payment. When these two sums are equal (meaning the consumer returns to repaying the original amount) the arrangement should be marked with an end date:
   • Where the two monthly payment values are equal, the flag will be dropped but the rest of the record carried forward.
   • For account types that do not display the revised monthly payment, the flag should be removed and the end date added.
   • Where the same record with a blank flag is subsequently submitted an end date of the arrangement will automatically be added to the record.
      

9. Debt management programme (M)

   The M flag should be used where the customer has entered into a debt management programme such as those run by the Citizens' Advice Bureau. The arrears against the original contract should be shown using the status code.

   • An M flag can only be set with statuses 0, 1, 2, 3, 4, 5, 6, D or U.
   • Two monthly payments will be shown on the CAIS record during a credit search – the current monthly arrangement amount and the original contracted monthly payment.
   • When these two sums are equal (meaning the consumer returns to repaying the original amount) the flag will be dropped but the rest of the record carried forward.
   • Where the same record with a blank flag is subsequently submitted, an end date of the programme will be added automatically.
      

10. Credit insurance claim (I)

    The I flag is set when the customer notifies the lender of the claim, along with a status of U for the life of the claim.

    • When the flag is used, 'CPI CLAIM' appears below the status summary lines.
    • If the flag is used without a status of U, the flag will be rejected but the rest of the record carried forward.
    • Where we are subsequently notified of the same record with a blank flag, an end date of the claim will be added automatically.
    • A record with a credit insurance flag is still expected to receive monthly updates until it is marked as settled or defaulted.
       

11. Account query (Q)

    Where a query exists on an account, such as a merchandise complaint or a dispute over a defaulted account, the record should be flagged with the letter Q and a status of U or 8.

    • If the account is sent with any status other than U or 8 the flag will be rejected but the rest of the input record will be processed.
    • Where the same record with a blank flag is subsequently submitted, the query flag will automatically be deleted.
    • A record marked as a query is still expected to receive monthly updates until it is marked as settled or is defaulted.

The following payment frequency indicators that can be supplied on a CAIS record:

The following definitions provide guidelines for creating CAIS records for consumer current accounts. The guidance given for CAIS status codes has been taken from the BBA (British Bankers Association) proposal to SCOR regarding current account sharing and recognises that the operation of current accounts is more flexible and varied than that of other types of account. They therefore recognise that definitions have to cater for a range of circumstances. For each CAIS status code there is a selection of criteria that may trigger its use. However, these conditions may not automatically trigger the status code because current accounts are subject to a greater degree of manual review than other account types.

Start date:

The date the current account was opened.

Settlement date:

The date the account was closed.

Default date:

For CAIS 8 records, this is the date at which the lender decides the account has gone into default – as defined below – and has decided to file a CAIS 8 against that customer.

Credit limit:

The 'overdraft limit' as disclosed to the customer. Any shadow limit that the customer is not aware of should not be supplied in this field. Sharing overdraft limits is not mandatory as some lenders manage current accounts taking the wider customer picture into account. Here, reporting apparent excess whilst managing the position internally with a different approach could be misleading. You should provide this where appropriate.

Current balance:

This should be the 'overdraft balance' and indicates how amount by which the account is actually overdrawn. If the current account is in credit the current balance field should be populated with zeros and the credit balance indicator should be left blank. The nature of current accounts means there are several ways to calculate the balance field. For example, you could give the average monthly balance or a ‘snapshot’ as at the day the field was created. You should use the most appropriate way of representing your data.

Status codes:

These definitions act as a guideline for creating current account status codes that are consistent with those for other types of CAIS records. ‘Possible triggers’ recognise that current accounts are more flexible and varied than for other account types. They should not be seen as over prescriptive and it is recommended that you give the status codes you feel are most appropriate to your product and business.

Status 0: possible triggers

Given when:

• the account is in credit
• no overdraft is currently requested
• an overdraft is not in excess of either the authorised limit or shadow limit (a limit, not disclosed to the account holder, which is greater than the authorised overdraft limit. The lender will not take any corrective action providing the shadow limit is not exceeded)
• the lender is comfortable with the situation and will not take any corrective action
• an arrangement flag is set and the arrangement is being in a satisfactory manner
• the account is within the agreed temporary excess.

Status 1: possible triggers

Given when:

• the overdraft balance is less than the overdraft limit or shadow limit but is between one and two months’ past the repayment date
• the overdraft balance is greater than the overdraft limit for between one and two months
• cheques, direct debits or standing orders bounced this month to keep the account in order
• the overdraft limit increased temporarily while managing balance downward
• the overdraft limit, which is not to be exceeded under any circumstances, is set and the customer is required to reduce the balance
• the overdraft balance is less than the overdraft limit for one month but no credit has been received for 35 days and the customer has not responded to a request that the account be funded.

Status 2: possible triggers

Given when:

• the overdraft balance is less than the overdraft limit or shadow limit but is between two and three months’ past the repayment date
• the overdraft balance is greater than the overdraft limit for between two and three months
• cheques, direct debits or standing orders are bounced for a second consecutive month to keep the account in order
• the account is being managed downward for a second consecutive month
• the overdraft limit, which is not to be exceeded under any circumstances, is set for a second consecutive month and action is taken to keep the customer within it
• the overdraft balance exceeds the overdraft limit for more than one month and no credit has been received for 35 days
• the overdraft balance' is less than the overdraft limit but no credit has been received for between 35-60 days and the customer has not responded to a request that the account be funded.

Status 3: possible triggers

Given when:

• the overdraft balance is less than the overdraft limit butis three months or more past the repayment date
• cheques, direct debits or standing orders are bounced for a third consecutive month to keep the account in order
• the account is being managed downward for a third consecutive month
• the overdraft limit, which is not to be exceeded under any circumstances, is set for a third consecutive month and action is taken to keep the customer within it
• the overdraft balance' is less than the overdraft limit but no credit has been received for more than 60 days, the customer has not responded to a request that the account be funded, and a formal demand for repayment has been sent.

Status 4-6: possible triggers

If status 3 has been set and the customer is showing no realistic attempt to repay the overdraft a status 8 would normally be set.

Stats 4-6 will normally only be needed if the customer has offered and is making a realistic effort to repay the overdraft, but the overdraft is more than three months beyond its repayment date and no formal arrangement is in place.

Status U: possible triggers

Given when:

• a new account of up to three months old has no activity during the last month
• the account has zero balance and no activity during the last month.

Status D: possible triggers

Given when:

• an account that is more than three months old has a zero current balance and no account holder activity (debit or credit transactions) during the last two months
• an account with a credit balance has no account holder activity (debit or credit transactions) for the last 12 months.

Status 8 – account in default: possible triggers

As with other types of credit, a number of factors may indicate that the contractual relationship with the customer has broken down. The below conditions must be considered alongside the Principles for the reporting of Arrears, Arrangements and Defaults at Credit Reference Agencies and the requirements under the banking code. The status code may be given when:

• the bank has demanded that the customer return the cheque guarantee card
• the account has been closed at bank’s request
• the overdraft balance has exceeded the overdraft limit for at least three months with no evidence that the account will be brought into order
• no substantive repayment has been made three months after the scheduled repayment date and no extension has been granted
• no credit has been recorded for three months.

CAIS flags – D, P, C, G, A, M, I, Q, S:

Provided where appropriate to their current account relationship.

Balance type:

CAIS members may calculate the current balance in a variety of ways and the flag should be used to indicate this appropriately:

• A indicates that the average balance in a month has been provided in the current balance field
• P indicates that the balance reflects the time when CAIS update was taken.

Credit turnover:

This field may be used for detecting money laundering activities and soft fraud, and assessing affordability. It should contain the value of all payments into the account during the last month, excluding any internal transfers from other accounts within the same organisation or group. It should also exclude any credit transactions from a savings account into the current account within the month.

Primary account indicator:

This field is used in assessing affordability. The performance of a primary account can be more predictive than a non-primary account. Populating this field indicates that you believe this record to be the customer’s primary current account, usually because the customer’s regular income is paid into the account.

Transactions flag:

This field is to indicate where cheques or direct debts from a current account have not been paid due to insufficient funds within the last month.

Below we’ve included guidelines for creating credit card and store card behavioural data-sharing fields within CAIS records, taken from the UK Cards proposal on behalf of credit and store card lenders. These fields will form part of the existing monthly CAIS data supplied for this type of account.

Payment amount:

This should include true payments only (not non-payment credits such as refund), credited to the account in the previous billing period after any reversals (such as a bounced cheque, direct debit or standing order). It may include multiple payments received in the same period.

The examples below show how the payment amount should be calculated. The guiding principle is to show the true net payment made within that particular payment cycle. Where the total of payment reversals is more than the total of payments made in that cycle, the payment amount will be negative.

Scenario 1

Customer pays £100 against their account in cycle 1 – payment amount field to show £100.

Scenario 2

Customer pays £500 in cycle 1 that bounces in cycle 1 and then pays £100 in cycle 1 – payment amount field to show £100.

Customer pays £500 in cycle 1 that bounces in cycle 1 and they pay £600 in cycle 1 – payment amount field to show £600.

Scenario 3

Customer has a credit balance of £200 on their account and has requested this is paid back to them – payment amount field to show £0.

Scenario 4

Customer pays in £200 in cycle 1 and has a payment reversal of £300 in cycle 1 – payment amount field to show negative £100.

Scenario 5

Customer pays £500 in cycle 1 that bounces in cycle 2 – payment amount field to show negative £500 in cycle 2.

Customer pays £500 in cycle 1 that bounces in cycle 2, then pays £100 in cycle 2 – payment amount field to show negative £400 in cycle 2.

Previous statement balance:

This field should contain the balance at the date of the previous statement date relating to the requested payment amount. This should be given in addition to the current balance field.

Cash advances:

This fields records the number and value of cash advances within the reporting period. This includes UK ATM transactions, foreign ATM transactions and over-the-counter cash, for example bureau de change. It should not include retail cashback or quasi cash transaction, credit card cheque transactions, gambling cash advances and any fees or charges.

It is best practice not to include any cash advances fee(s) which, if recorded, do not add to the field for the number of cash advances count.

Payment code:

This is to indicate where only the minimum requested payment has been made by the customer. An M should be given where a payment is within a one pound tolerance either way of the expected amount, with any pence rounded to the nearest pound. Any other payments should be set to blank to indicate the minimum payment was not made.

Promotional activity:

This field is used to indicate any form of current promotional activity on the account. This may reflect new or life of balance rates, whether purchase, balance transfer, credit card cheque, or other promotions. This relates only to accounts that are actually benefiting from the promotion.

Where a loan is a ‘buy now pay later’ arrangement:

• The balance should reflect the full amount of the loan until payments start, when it should decrease in line with the payments made.
• The monthly payment should be 0 until payments start, when it should show the actual payments being made.
• The status code should be U until payments start, when it should reflect the payment record for each month as normal.

Where a loan is a 50/50-type deal and an amount (for example, 50%) has been put down as a deposit at the start, with the remainder payable as a lump sum at the end of the term:

• The balance should equal the final lump sum payment until this final payment is made, when the balance should be shown as settled or give the actual amount outstanding.
• The monthly payment should be 0 until the final lump sum payment, when it should show the final payment.
• The status code should be U until the final lump sum payment, when it should reflect the payment record for that month as appropriate.

Where a loan is a 50/50-type deal and normal amounts are paid throughout the term with a single lump sum payable at the end:

• The balance should equal the full amount of the loan, decreasing in line with the payments made until just before the final payment, when the balance will typically be the final lump sum payable.
• The monthly payment should be whatever is being paid monthly until the final payment.
• The status code should reflect the payment record for each month as normal including the final lump sum payment.

Where a loan is a 50/50 deal and an amount (for example, 50%) has been put down as a deposit at the start and the remainder is payable as normal over the life of the term:

• The balance should equal the amount left outstanding on the loan.
• The monthly payment should be the actual payment being made each month.
• The status code should reflect the payment record for each month as normal.

SCOR mandated a group to look at the way data is shared for flexible and current account mortgages. The group included a number of lenders that offer or are about to offer this type of product, together with a representative from the Council of Mortgage Lenders and credit reference agencies.

What is a flexible or current account mortgage?

For the purposes of this guide, a flexible or current account mortgage is defined as:

• having an underlying mortgage
• having a current account of some form, potentially with overdraft facilities
• potentially featuring other credit products such as credit cards and personal loans
• potentially featuring savings accounts
• a product that was sold to the consumer as a total solution
• viewed by the consumer as one product with a number of underlying features
• a product where the lender views the consumer’s debits and credits in a holistic way for risk purposes.

For tax reasons this guidance is not designed to include products that are netted for interest purposes.

Guidance for supplying flexible mortgages

The group agreed that the current method of some lenders providing a net position and some reporting the constituent parts is could be confusing for both consumers and lenders. Reporting of numerous accounts could also have a negative impact on scoring models.

It was decided that such products should be identified as a specific product type so they can be modelled and scored separately, if analysis indicates that it is appropriate. A new product type – ‘flexible mortgage’ – was created for CAIS submissions.

Since lenders and consumers consider the net situation on such accounts, and it is impossible for other members of the shared database to identify the constituent parts, it is further recommended that the net position be reported on the one flexible mortgage. This enables the total exposure position to be accurately reported to CAIS, taking into consideration credit and / or advance payment positions on other accounts in the overall product.

Where applicable, CAIS members should share the:

• advised limit
• current debit balance (mandatory)
• period of loan
• repayment amount.

Other appropriate CAIS fields – for example, start date, flags – should also be shared.

The Competition Commission requires larger home credit lenders to share their customer credit accounts with credit reference agencies.

These definitions are agreed with the Consumer Credit Association, Competition Commission and Information Commissioner’s Office. The rules recognise that home credit accounts are more flexible and varied than that of other types of account, so the definitions have to cater for a range of circumstances. In particular, as most home credit accounts work on weekly terms, the loan term and the amount outstanding must be calculated and recorded as a monthly figure so it can be easily compared with other credit accounts on CAIS. Also, there will be situations when a CAIS status code 6 is recorded for longer periods of time.

Monthly payment: 

This field shows the value of, and is equivalent to, one month of weekly payments. For consistency, this value should not be changed during the term of the loan, even when the number of days in the month differ. The monthly payment value is calculated by multiplying the weekly payment by 4.33. The field should only record whole pounds, without rounding up or down, so £10.23 and £10.78 would both be recorded as £10.

Repayment period:

This field gives the term of the loan. Standard practice in the home credit market is to grant loans over a number of weeks. For data to be comparable to other credit accounts on CAIS, any loan term of weeks must be converted into monthly terms. For consistency the monthly value should be calculated by dividing the weekly term by 4.33 and rounding up. So a 12-week loan would be recorded as three months, a 13-week loan would be recorded as three months, and a 14-week loan would be recorded as four months.

CAIS account status codes:

The status code is a monthly indication of the payment performance of the account. An unclassified status code (U) is used the first time an account is reported to CAIS. It shows the first payment is not yet due or allows time to make sure any customer issues with the credit agreement are raised before performance reporting is started.

Account status codes indicate the number of months in arrears a credit account is in. Home credit accounts status codes should be calculated by dividing the total value of arrears by the Monthly Payment value. Only full months arrears should be reported and any part months’ arrears should be rounded down. In allocating a status code 1 to indicate an account moving into arrears, it is advisable to include a seven-day period of grace, to allow for a payment which has been unusually delayed.

Defaults (status code 8):

According to the ICO, a default occurs when the relationship between the borrower and lender has broken down. For home credit, this occurs when:

• no repayments are received for a minimum of three months, without arrangement
• the customer has disappeared and cannot be traced
• the customer is declared bankrupt.

No default is filed even if the customer is making part or irregular payments without an arrangement being in place, with the customer is held at status code 6 for up to 12 months. If a default is filed on such accounts at a later stage, the default date should be backdated to the date the first status code 6 was reported. The nature of the home credit market means this would only happen in unusual circumstances.

Payment frequency indicator:

This field shows how often payment is received. Home credit accounts on weekly terms will include a W in this field. The contents of this field have no effect on the monthly payment field, which is calculated separately to give a monthly amount.

Flag settings:

Flags are used to give a more detailed picture of an individual’s current position. They have a hierarchy and where more than one flag applies, the flag with the greatest hierarchy is submitted.

For home credit accounts, the flags are:

CAIS flag Description

D Deceased

P Partial settlement

C Debt assigned (non-CAIS member)

S Debt sold to CAIS member

G Gone away

A Arrangement

M Debt management programme

Q Account query

Arrangement (A):

If the customer and lender have made a formal agreement to reduce the monthly payment amount for a limited period of time, an A flag is used. The payment terms are amended to the new agreed payments, and the payment profile updated accordingly. Any arrears accrued against the original contract continue to be shown by the appropriate status code before the date of the arrangement, together with an A flag and the arranged monthly payment at that particular time.

In instances where smaller payments are accepted, but no formal re-scheduling of the agreement is made; an A flag should not be reported. In these cases the status code should be based on the new agreed rate, rather than the contractual rate.

Debt management programme (M):

The M flag is used when the customer has entered into a debt management programme with a separate company. The status code reflects the arrears at the time the program was entered into. After the customer enters the program, two monthly payment amounts are recorded on CAIS – the revised (managed) amount and the original monthly payment amount.

Since 1990, government-funded loans have played a key role in students’ access to higher education. From 1990 to 1998 these loans were regulated by the Consumer Credit Act 1974 and were sometimes referred to as ‘mortgage-style student loans’. Customers who took out these loans receive an annual statement and interest is also adjusted annually.

The two main differences between student loans and other types of credit are that:

1. If the borrower is on a low income (defined as 85% of the national average) payment may be suspended through a process known as deferment. This must be sought and agreed each year.

   The deferral is effectively a payment holiday similar to other credit agreements that have a deferred start or the possibility to take a holiday. A deferral on a student loan will be reported as U.

   If the borrower applies for deferral but is already in arrears, either because they were late in applying for deferral or because there were already arrears on the account before deferral was possible, there may be records showing an arrears status followed by a U. It should not be assumed that the arrears have been brought up to date.

2. The debt may be cancelled if the borrower:
   1. dies
   2. took out loans before they were 40 and is now 50
   3. took out a loan before they were 40 and it has been outstanding for 25 years
   4. took out a loan when they were over 40 and is now 60
   5. is deemed to be permanently disabled.

These accounts will be marked as P.

Account type:

The student loans account type 60 should be set on all student loan records.

Status code:

On a full CAIS record, normal status codes will apply. While a consumer defers payment this is reported into CAIS as a status of U until the loan becomes payable.

Arrangements:

Can be reported on student loans, including those in status U – for example, if an agreement has been reached to repay arrears incurred before eligibility for deferral.

Start date:

Given as the first scheduled repayment date.

Definition of default:

The account is not in a viable arrangement and is 180 days past due.

Original default balance:

If an account is in deferral but has previous arrears every effort will be made to establish a repayment programme for the outstanding arrears. If this is not possible, the account will be brought out of deferral and default proceedings commenced. The default will be registered for the full amount owed.

This type of loan allows consumers to borrow a relatively small amount of money (usually between £50 and £1,000). It’s a short‐term, high-interest, unsecured loan that’s expected to be repaid when the consumer receives their next regular income payment (normally around or within 30 days of having been granted the loan). It’s not designed for longer-term borrowing, but to improve short-term personal cash flow.

Where the balance outstanding is rolled over to the following pay day, you should ensure that the same account number currently reported to CAIS is updated to ensure a continuation of the payment and status code history.

Where the consumer wishes to take out additional lending this would be deemed to be a new agreement and the account number on CAIS is reported with a closed date and the current balance set with zeros. A new account number is then reported for the new agreement.

Accounts that are opened and closed within the same month of CAIS reporting are reported as closed with a zero balance on the CAIS extract. This shows other CAIS members that a lending agreement was previously in place.

CAIS fields include:

Balance:

The balance outstanding reflects the total amount of the loan and includes any interest and charges that have accrued over the life of the agreement.

Monthly payment:

Where a monthly payment is agreed this field reflects the agreed amount. This field is not always applicable – for example, where a payday loan agreement is paid either within the same CAIS reporting cycle or is paid in full the following month.

Status codes:

In line with the Principles for the reporting of Arrears, Arrangements and Defaults at Credit Reference Agencies, payday loan lenders must allow a minimum of 90 days of arrears and a 28-day notice period before reporting an agreement in default.

• Status code 0: up to date or new records being reported for the first time.
• Status code 1: day 30 and over.
• Status code 2: day 60 and over.
• Status code 3: day 90 and over. A default notice can be issued at this stage if payment is not received and the relationship with the consumer is deemed to have broken down. If there is no response within 28 days a default can be registered.

If a default is not registered at this stage the account can go to a maximum of 180 day overdue and progress through the arrears status codes as per standard CAIS reporting. Once an account is 180 days overdue a default should be registered. To prevent the account from continually being reported in arrears an arrangement to pay could be agreed with the consumer.

• Status code 8: default.

Energy

Energy accounts can be reported into CAIS in line with all other credit agreements. The exception is pre-payment meters. Where a consumer signs up to energy supply on a pre-payment meter from the onset, this will never be reported into CAIS. Where a pre-payment meter is fitted as a result of arrears, only payments made to clear the arrears are reported, not the on-going consumption via the pre-paid meter. Once the warrant process is underway, and provided the account is over 90 days in arrears, a notification of intention to file a default may be sent to the consumer and a default registered 28 days later. This is in line with the Principles for the reporting of Arrears, Arrangements and Defaults at Credit Reference Agencies.

Water

As with many non-standard credit products there are specific rules for the sharing of water accounts data. Water providers do not have the choice of ceasing to do business with a defaulting customer, which brings added complexity. This may lead to them continuing to provide the service and, potentially, finding themselves in a similar position of default from that customer again. This means water accounts need to be recorded slightly differently.

However, to be consistent with other data providers, defaults should be registered after 90 days and before 180 days of non-payment, in line with the Principle for the Reporting of Arrears, Arrangements and Defaults at Credit Reference Agencies.

As long as they are clearly communicated to the customer or business, a number of triggers may be considered to be grounds for registering a default:

• Where the supplier takes or has taken legal action or steps to cut off the service (or would do so if they were not prevented on social rather than commercial grounds or by other regulations, codes of practice or statute).
• Where there is evidence that the customer has left the property without making payment or arrangements to pay.

Even though the service cannot be disconnected, default should still occur within the normal timescales of between 90 - 180 days past due. In these cases the water provider will register a new account or agreement will be commenced within their internal systems to register the ongoing supply. Providers supplying positive as well as negative data will register a second account on CAIS and the performance on that account will be supplied as normal.

To prevent a large volume of defaults for the same product type and from the same supplier being reported, just one default can be registered over a six-year period. So at any time during a six-year period a customer should have a maximum of one defaulted account and (potentially) one active full data record. The balance on the defaulted account will change as more defaults are added and settlements occur. The only time that this may change is if there is a break in the incidence of defaulting, where one default is satisfied and another default is registered.

If you’ve sold on a customer record to another company or Debt Collections Agency (DCA), there is still an obligation to bring the CAIS record to a complete end.

This is carried out through the use of a flag setting within the monthly submission that will update the record to reflect the debt sale.

How should this be reported to CAIS?
A common misconception is that records that have been sold, should be deleted.

This is inaccurate advice and would not create a true reflection of the account activity.
Deleting the record would cause it to disappear from any credit searches or credit reports meaning lenders and consumers alike would no longer be able to view the account data.

The correct course of action in this scenario is to apply a debt sale flag to your CAIS record, report as settled/satisfied, with a zero-current balance outstanding.

Once these changes have been updated on your monthly CAIS file, you no longer need to supply a record for that CAIS account.

Which flag setting should be applied?
There are two debt sale flags that can be applied to a record through the monthly file:

C - where the record has been assigned to a non-CAIS member.
S - where the record has been sold to a CAIS provider.

When should this be reported?
The changes should be reported on your CAIS input file in the very next submission following the debt sale.

What is the impact to the consumer?
The ultimate outcome is that the CAIS data is reported and retrieved with a high degree of accuracy for both consumer and lender, with no loss of data. This leads to better lending decisions for clients, and a customer journey that shows a logical progression for the life of the account.

Where can I find more information?
Details on how to apply the debt sale flag and report into CAIS can be found in the frequently asked questions section of the website and the CAIS2007 format guide.

UMAs are also known as Active Without Updates (AWUs) if you fail to update an active/open account each month, it will cause the whole record to become frozen, viewable at the status it was when it last received an update. This is known as an Unmatched Active.

How should this be reported to CAIS?
All active (open) records must be updated (by reference to the account number) each month, even if there is no movement on the account, until they become either genuinely settled or defaulted.

What is the impact to the consumer?
Unmatched Actives can create consumer queries and complaints to either Experian or directly to our clients. The account balance may not be accurate which would affect the overall balance a consumer owes on their credit report; the account may have been settled by the consumer which would indicate to other lenders that the consumer can successfully complete a credit agreement; the account could be delinquent (consumer has fallen behind on payments for at least 3 months) or even defaulted (the credit agreement has broken down). If we receive a subsequent update to an Unmatched Active, our systems will auto-fill the missing months status history with a question mark(?) which could also cause consumer queries.

Where can I find more information?
You can email the Consumer CAIS team at cais.control@experian.com or call 0115 9768933 for more information. If potential project work is required, please email cais.consultancy@experian.com. Unmatched Actives are also referred to in the bi-annual CAIS Audit document under section 7 of the audit report.