FAQs - Policy and business

The reporting of Individual Pension Transfers as a separate Product under Code 20 only applies in respect of those that are a 'pension transfer' as defined in the FSA Handbook . This is essentially those that involve the transfer of benefits from an occupational pension scheme to a private pension arrangement (eg a personal pension, SIPP or stakeholder pension), which would normally involve the advice of a pension transfer specialist. The definition can be found in the Handbook Glossary.

Income drawdown is reportable under product code 24 when a member exercises the option to take income withdrawals. It is the initial decision to enter into a drawdown arrangement that is of interest to us. The value to be reported should be the amount of the funds the member has elected to put into the drawdown arrangement. If the drawdown is on a phased basis, each individual transaction will not be reportable separately.

If, however, the member elects to enter into a subsequent new drawdown arrangement, then this would be reportable separately.

The definition can be found in the Handbook Glossary.

As the PSD Data Reference Guide shows, you will not be able to enter a nil value as the value range is from 1 to 999999999. If for some reason the first premium is zero, please enter a value of 1.

The date in force should be the date the wrapper was set up. If the first premium is zero (in such cases where there is no premium at outset), please enter a value of 1.

If a pension transfer coincides with joining the SIPP, we would expect it to be reported under both product codes 20 and 30 even if that means some double counting. We are interested in how many people join SIPPs and separately how many pension transfers happen. Pension transfers into existing SIPPs should be reported under product code 20 only.

A similar answer applies for income withdrawals (product code 24) as for pension transfers (product code 20). We want to know whenever these happen. It could be under an existing SIPP (just product code 24), or it might happen on joining a SIPP (product codes 24 and 30).

The focus for PSD reporting is on the product provider not the asset manager nor any other ancillary or intermediary. If you are the provider of the underlying investment, you will need to include it in your PSD report under the relevant product type.

PSD only includes initial data, with regard to SIPPs reporting, we will require you to report data when new members join the scheme. PSD does not include increases in regular premiums, nor does it collect single premiums to existing contracts. Also, it does not include the start of regular premiums under existing single premium contracts.

You should try to estimate the total value of all contributions and all assets transferred into the SIPP, including those investments that would not be classed as 'designated investments' such as property and cash.

If interest is calculated daily or monthly and overpayments can be made at any time without a penalty being applied, the mortgage should be reported as a flexible product.

If the mortgage is, for example, part fixed and part discounted, you should report the interest rate type that applies to the largest portion of the overall mortgage balance. If there is a 50/50 interest rate type split you can decide which interest rate to report. However, when reporting the loan size, you should report the total loan size regardless of the interest rate split.

The definitions for impaired credit mirror those that are used for MLAR reporting purposes. Each of the specified criteria is included as a basis of assessing a borrower's past performance in dealing with loans. Many people’s only credit exposure before applying for a mortgage may have been an unsecured loan, so it is important that unsecured lending is included.

However, we can confirm that we view ‘unsecured loans’ as excluding any form of revolving credit, e.g. overdrafts and credit cards.

The right to buy (RTB) category. Where the borrower is a first time buyer (FTB) and is also exercising their right to buy, we are more interested in knowing that the borrower is a RTB borrower rather than a FTB.

In general the answer is yes. However, for the data in the tables for mortgages (c), the shaded boxes indicate that providing the data is not mandatory but must be reported if applicable. This applies to the following data fields:

• mortgage characteristics;
• purpose of remortgage
• County Court Judgements (CCJ) value; and
• impaired credit history of main borrower.

We deal with this in the PSD Data reference guide in the comments section for the 'Value of Mortgaged Property Field'. You should only report the mortgage when the final instalment has been advanced to the borrower. The loan size reported should the total loan advanced.

In such circumstances we realise that it is very difficult for lenders to say whether a specific loan is secured against a specific security: so if the package includes a residential property as a security, and which would normally be part of a RMC, it is difficult for the lender to identify the precise loan that matches it.

It has therefore been agreed that in the circumstance you have identified i.e. where a borrower has several loans secured against several securities but where there is no specific 1-1 correspondence between a specific loan and a specific security, these transactions should not be included within the PSD return.

However, where there is a 1-1 correspondence we would expect these loans to be included within the PSD return.

To clarify, the requirement to report from April 1 2005 applies to any mortgage that completes from April 1 onwards.

You should report these mortgages using the interest only/unknown option in the method of repayment field, and as if they have a 1 year mortgage term.

This should be reported as a remortgage.

In line with past PSD guidance, we would expect firms to report the entire loan amount in the size of loan data field, but the characteristics applicable to the largest portion of the loan should be reported (in this case the conventional mortgage piece). If both portions of the loan (the equity loan and the conventional mortgage) are the same the lender can choose which element to report but the entire loan amount would still need to be reported.

"SA = the loan is a shared appreciation mortgage" should be completed in the Mortgage Characteristics data field, and "F = First time buyer" or "M = Home movers (2nd or subsequent buyers)" should be completed in the Type of borrower data field.

This should be reported as a conventional mortgage and "C = council / registered social landlord tenant exercising their right to buy" should be completed in the Type of borrower data field.

This should be reported as a conventional mortgage.

The entire loan amount should be reported as a remortgage.

Where a product was 'closed' for new business as at 1 April 2005, or where the new business from that date has been restricted to increments to existing business and new members to existing schemes where the expected number of new members is minimal arising from a passive sales process, the firm will not be required to include sales relating to this product.

You only have to report the individual contracts.

Holloway contracts should be reported. We consider these sales to be most appropriately reported under the Retail Investments section, and the "other" product type code should be used for this purpose.

Yes. The current PSD reporting requirement only applies to the income drawdown element.

The TRS system will only allow you to report one type of premium per transaction. So if a product is set up with a regular and single premium, the regular premium transaction should take precedence.

While it would be preferable for 'non private' sales to be excluded from your PSD return, if it is not possible for you to do this, then you can include all transactions in the report.

To clarify, PSD currently only relates to the customer’s initial investment so you do not need to report switches or further contributions (top-ups).

We are aware that, in most instances, the underlying customer data is held by the nominee firm and not by the CIS operator. So, although we intend revisiting this issue at a future date, the interim position we have agreed is as follows.

• Nominee deals and deals via life companies will be excluded from the scope of PSD reporting.
• However, if the CIS Operator arranges deals through an in-house ISA manager (that is part of the same group of companies) it should – where possible – include all individual personal holdings on the register in the PSD return.

We will re-consult on extending the scope of PSD reporting to external ISA managers, non-operator ISA managers, other platforms, fund supermarkets and aggregators at a later date.

We will be issuing a revision to the rules in a future Handbook Notice Update.

All relevant transactions from 1 April 2006 should be reported with the advised/non-advised information.

By advice we mean the regulated activity of advising a client on the merits of entering into a particular contract. We want to know whether the customer received advice from the product provider or their intermediary before buying the product.

If the provider undertook all reasonable steps to get the advised/non-advised data but was not able to obtain this info rmation from the intermediary firm, they may be able to make reasonable assumptions about whether the sale was likely to have been advised or not.

Direct offer sales should be reported as non-advised sales.

As the firm will not be giving advice itself, these transactions can be treated as non-advised.

In these cases it can be assumed there was no advice given.

If no information is provided, the default position for broker sales should be to assume advice was given.

If a sale is made by an intermediary firm who is an appointed representative of a network/principal, we require you to report the FSA reference number of the AR and the FSA reference number of the network or principal.

Firms are required to notify us of the product sales which fall within the relevant reporting quarter. So a firm should not notify us of a transaction until it is on risk. As such, you should report your transactions when you put the policy on risk (presumably, after you have conducted medicals etc).

However, if you put your customers on risk once you receive the application, then this is the date you should report. If this is the case, then you may have reported sales which then do not occur. In these instances, the system will, if necessary, give you the opportunity to cancel the original individual transaction you reported to us.

If you notify us of a system failure, we will extend the reporting period until your firm is able to comply with the requirements. We cannot accept data in any other format than an XML file.

If a firm does not have an FSA reference number, sales made by these firms should not be included within the PSD submission.

In cases where the firm does not have an FSA reference number, any sales made by the firm should not be included within the PSD submission.

Please note that the cancellation would need to occur using the same method as the original transaction report.

However, any replacement transaction could be submitted via any route including manual keying.

Although a third party can submit a PSD return on your behalf, they will need to use your firm’s FSA reference number and logon details to submit the return. (You should note it is your responsibility to manage the security of these logon details with your third party firm).

In fact, all contact from us will be with your firm and not the third party. So, when we provide your target registration and certification date, you will need to make your third party aware of this date to make sure this date is okay for them. If not, you must tell us so we can arrange another target registration date.

On the target date (or registration date) we will provide the principal contact at your firm with the access and login you will need to give the third party so they can submit PSD on your behalf. We will tell the principal contact that we have received the file and will also advise them of any problems with the file (e.g. schema successes or failures).