REP017 Payments Fraud Report: UK Rules, Deadlines and Data Fields

Regulation 109(4) of the Payment Services Regulations 2017 requires each payment service provider in the United Kingdom to give the FCA statistical data on fraud relating to different means of payment, and the FCA collects that data through a single form: the REP017 payments fraud report. Every return covers one half-year, 1 January to 30 June (H1) or 1 July to 31 December (H2), and SUP 16.13.8D sets a two-month filing window, measured from the end of each half-year for most providers and from the end of the calendar year for small payment institutions, small e-money institutions and registered account information service providers.

The form’s definitions decide which provider reports a given leg of a payment and which team owns each number. The FCA’s completion notes, last revised on 1 January 2021, sit on top of a 2019 form and the EBA’s 2018 fraud reporting guidelines, and several gaps between those three documents land on cells a filer has to complete.

Related reading: PSR Specific Direction 20: APP Scam Reimbursement Reporting

Legal basis for REP017: regulation 109(4) of the PSRs 2017 and the SUP 16.13 directions

The statutory duty is short. Regulation 109(4) applies to each payment service provider in the UK, carving out agents of a payment service provider and “excluded providers”, and requires statistical data on fraud relating to different means of payment. Regulation 109(5) adds that the data must be provided at least once per year and in such form as the FCA may direct. Regulation 2 defines an excluded provider as a provider of services within paragraphs 2(k)(i) to (iii), (l) or (o) of Schedule 1: the limited network, electronic communications and cash withdrawal exclusions.

The FCA exercises that direction power in SUP 16.13. SUP 16.13.2G states that the section gives directions under regulation 109(5) about the form of the fraud data required by regulation 109(4). SUP 16.13.7D then requires the data to be submitted by electronic means made available by the FCA, using the format of the return in SUP 16 Annex 27ED, and points to the completion guidance in SUP 16 Annex 27FG. SUP 16.13.8D fixes frequency, periods and due dates.

The suffixes matter when a policy document cites the Handbook. The “D” on Annex 27E marks a direction; the “G” on Annex 27F marks guidance. The binding layer is regulation 109 together with SUP 16.13.7D and 16.13.8D. Annex 27F explains how to complete the form, and a procedure that quotes it as the source of the obligation has the hierarchy upside down.

Underneath sits the EBA text. SUP 16.13.8AG says the return reflects the EBA’s Guidelines on fraud reporting under PSD2, published on 18 July 2018 (EBA/GL/2018/05), and that it also covers fraud reporting by registered account information service providers as regulation 109 requires. The FCA’s Payment Services and Electronic Money Approach Document says payment service providers are required to make every effort to comply with those guidelines, which specify the data to be reported, and that the FCA implemented them in the form of REP017. The completion notes are written to be read alongside them. Our PSD2 reporting requirements guide covers the EU-side reporting streams, including the fraud reporting that Article 96(6) PSD2 mandates.

REP017 is one of several PSRs returns, and the neighbouring ones answer different questions. REP018, the operational and security risk reporting form, is listed against regulation 98(1) in the Approach Document’s Chapter 6 table of reporting requirements for firms in the temporary permission scheme; Chapter 13 says the report is required under regulation 98, while the Handbook notes at SUP 16 Annex 27H describe the assessments attached to the form as made in accordance with regulation 98(2) and SUP 16.13.13D. Regulation 98(1) concerns the underlying management of operational and security risk, and incident reporting sits in regulation 99. REP017 counts transactions and fraud values for a half-year, while the other two deal with risk assessment and incidents.

Who must report REP017: five Handbook categories and a wider statutory definition

SUP 16.13.6G lists the payment service providers to which the fraud data requirement applies:

• authorised payment institutions;
• small payment institutions;
• registered account information service providers;
• electronic money institutions;
• credit institutions with permission to accept deposits under Part 4A of FSMA.

The Approach Document’s reporting summary says the same in shorter form: all PSPs, naming credit institutions, payment institutions, e-money institutions and RAISPs. Every listed category reports, and a provider’s category sets only its reporting frequency; the calendar for small payment institutions, small e-money institutions and RAISPs is set out in the deadlines section below.

The statutory definition of payment service provider in regulation 2 reaches further than the Handbook list. It also names Post Office Limited, the Bank of England (except when acting as monetary authority or carrying out other public functions) and government departments and local authorities (except when carrying out public functions). SUP 16.13.6G does not mention those bodies, and none of the FCA sources reviewed for this article says how REP017 applies to them.

Which part of the form each provider completes

Scope inside the form follows the service, and the allocation rules decide whether a figure is counted once, twice or not at all. The completion notes set the general rule: for all payment services the payer’s provider reports, except direct debits, which the payee’s provider reports, and card payments, which both the issuer and the acquirer report. EBA Guideline 2.11 adds the tie-breaker for chains with more than one acquirer: the acquirer with the contractual relationship with the payee reports.

• Registered account information service providers, meaning providers of AIS and no other payment service, skip Table 1 and complete Table 2 only. Any other firm that provides AIS completes Table 2 as well, per the template’s own instruction.
• E-money issuers report e-money payment transactions in their own section. The card sections are headed “except cards with an e-money function only”, so a prepaid e-money card’s fraud belongs in the e-money block.
• Money remitters report a single total row, and PISPs report the transactions they initiated in rows 200 to 208. The provider executing a PISP-initiated credit transfer also shows it, as an “of which” line, in row 3.

REP017 identifies the reporting entity by its FCA Firm Reference Number (FRN). FCA FRNs may contain six or seven digits: the FCA began issuing seven-digit FRNs on 18 July 2023, while existing six-digit FRNs remain valid. Reporting controls should use the entity’s assigned FRN rather than assume that all FRNs contain six digits. Neither the directions nor the notes provide for a group or consolidated version, so each FRN in a group answers for its own transactions. The credit-institution limb of SUP 16.13.6G is framed by Part 4A deposit-taking permission and says nothing separate about branches; the EBA’s branch rule in Guideline 4.4 is written for branches in EEA host Member States and has no UK counterpart in the notes.

What the REP017 payments fraud report contains: Table 1 by payment service, Table 2 for account information

The FCA Handbook REP017 form includes Question 1 to identify the relevant reporting half-year. The completion notes explain how small payment institutions, registered account information service providers and small electronic money institutions use the period selection when submitting their two half-year returns together after year end. Any additional header fields and their mandatory-input rules should be confirmed against the current RegData data item.

The sections of Table 1

Most transaction-reporting rows use columns A to L: columns A to F record payment transactions and columns G to L record fraudulent transactions, each with domestic, cross-border within-EEA and cross-border outside-EEA breakdowns. The form also contains exceptions.

Fraud-type rows use columns G to L only (the notes list them, for example rows 8 to 10, 12 to 14, 23 to 25 and 27 to 29 for credit transfers and 158 to 163 for cash withdrawals). The rows that break non-SCA transactions down by reason for not applying strong customer authentication use all twelve columns A to L on the form, and the notes give them as ranges such as 15A to 20L, although the notes’ narrative speaks only of fraudulent volumes and values. The liability-loss rows use column A only. The loss rows are 35 to 37, 45 to 47, 100 to 102, 152 to 154, 164 to 166 and 196 to 198.

The geography split outlived Brexit by instruction: the FCA notes tell providers to keep reporting the domestic, cross-border within-EEA and cross-border outside-EEA breakdowns notwithstanding the UK’s withdrawal from the EU, but do not explicitly define how a UK-to-EEA transaction should be classified. EBA Guidelines 4.5 and 4.7 distinguish transactions between providers in different EEA Member States from transactions involving a provider inside the EEA and another outside it. The intended FCA treatment of UK-to-EEA payments therefore requires confirmation before those transactions are assigned to a geographical reporting column.

Channel, authentication and the reasons for not applying SCA

Below each total, the form drills down. “Initiated non-electronically” covers paper-based payments and mail or telephone orders. A remote transaction is one initiated via the internet or through a device that can be used for distance communication, the regulation 2 definition. Each remote and non-remote block then splits into transactions authenticated with and without strong customer authentication, and card blocks split by debit function against credit or delayed debit function.

For fraud authenticated without SCA, the form asks which exemption applied, and the list differs by section. Remote credit transfers carry low value, payment to self, trusted beneficiary, recurring transaction, secure corporate processes and transaction risk analysis. Non-remote card payments carry trusted beneficiary, recurring transaction, contactless low value and unattended terminal for transport or parking fares. The acquired-card blocks carry fewer still: three reasons remote, three non-remote.

What counts as a fraudulent transaction

For Table 1, a fraudulent transaction is one the provider executed, acquired or (for a PISP) initiated, and that it deems to fall into one of two categories. The first is unauthorised payment transactions, including those resulting from the loss, theft or misappropriation of sensitive payment data or a payment instrument, whether or not caused by the payer’s gross negligence. The second is manipulation of the payer: a payer deceived by a fraudster into issuing a payment order, in good faith, to an account the payer believes belongs to a legitimate payee.

Three boundaries follow from the notes. A qualifying transaction is reported whether or not the provider had primary liability to the user, and whether or not another provider in the chain also reports it. Fraud committed by the payment service user, first-party fraud, stays out. And the manipulation category is wider than what the UK calls authorised push payment fraud: the notes say APP fraud is restricted to credit transfers, while REP017’s manipulation types also appear under direct debits, card payments, cash withdrawals and e-money.

The fraud types themselves are section-specific. Credit transfers and e-money use issuance of a payment order by the fraudster, modification of a payment order by the fraudster, and manipulation of the payer. Direct debits use unauthorised payment transactions and manipulation of the payer to consent to a direct debit.

Cards split issuance by a fraudster into lost or stolen card, card not received, counterfeit card, card details theft and other. Cash withdrawals drop card details theft. Money remitters and PISPs report “fraudulent transactions” without a type split, using their own discretion on what to count.

Units, currency and losses

The FCA’s completion notes require REP017 values to be reported in pounds sterling. EBA Guideline 2.2 specifies transaction volumes as counts and transaction values in actual monetary units, with two decimal places. The current RegData data item should be consulted for the precise display labels, numerical formats and restrictions on negative inputs.

The loss rows behave differently from the transaction rows. For credit transfers, direct debits, card payments, card payments acquired, cash withdrawals and e-money payment transactions, the form asks for losses due to fraud by liability bearer: the reporting provider, the payment service user and others; money remittances and PISP-initiated transactions have no loss rows. The notes define the reported figure as the residual loss finally registered in the provider’s books after any recovery of funds, recorded in the period in which it reaches the books, as one figure for the period unrelated to the transactions reported in that period. Refunds from insurers are left out of the figure.

Table 2: fraud relating to account information services

Table 2 is a single row with three cells. 209A is the number of incidents of fraud the AISP recorded; a zero ends the table. 209B is the value of fraudulent transactions executed or initiated by a third-party provider as a result of the fraud where known, or otherwise an estimate of the loss to the persons defrauded, which can include the AIS user, another provider and the AISP itself, and can cover indirect losses such as reissuing payment instruments or fixing breached security systems. 209C describes the fraud. Non-sterling amounts are converted at the average ECB reference rate for the period where available, otherwise at the average of the Bank of England’s daily spot rates.

REP017 deadlines and reference periods: the half-year calendar and the adjustment window

SUP 16.13.8D sets two calendars. The reference periods never move; the filing window depends on the category.

The second row is the easier one to misread. An annual filer holds its H1 data and submits it alongside H2 within two months of 31 December, as two separate returns labelled through Question 1; for that filer, 30 June only closes a period. For a semi-annual filer, whichever half-year is running falls due two months after it closes. The sources reviewed state the window in months and print no calendar date; RegData can display a firm’s tailored reporting schedule, according to the Approach Document.

Where a due date lands on a day that is not a business day, SUP 16.3.13R(2) moves it to the first business day afterwards, and SUP 16.13.3A applies that timely-reporting rule to authorised payment institutions, small payment institutions and RAISPs.

Which period a transaction belongs to

The notes fix the recording date as the day the transaction was executed. Fraud enters the data from the moment it is detected, whether through a customer complaint or the provider’s own discovery, even if the case is still open when the return is filed.

Two consequences follow. Payment service users can claim redress for unauthorised transactions notified up to 13 months after the debit date, so fraud can surface after the period that holds the transaction has already been filed. And an open case that later proves not to be fraud has to come out again. The notes direct both kinds of correction into the next reporting window after the information is discovered.

The 2019 starting point

The FCA template carries a transitional note for the period 1 January to 30 June 2019: data for it was to be provided on a best-endeavours basis under SUP TP 1.2 13E. The EBA guidelines applied from 1 January 2019, except for the SCA exemption breakdowns, which applied from 14 September 2019. A firm newly authorised or registered part-way through a half-year faces a question the sources reviewed do not answer: neither the directions nor the notes say whether the first return covers the part-period or begins with the next full half-year.

Submission of REP017 through RegData: the form, the Excel template and resubmissions

SUP 16.13.7D requires submission by electronic means made available by the FCA, and Annex 27E repeats that firms must submit the returns using those means. The FCA’s reporting system is RegData: on 19 May 2021 the FCA announced it had completed the move of 52,000 firms and 120,000 users from Gabriel to RegData and stated that data items and relevant forms had not changed as a result. The May 2026 Approach Document still writes the method of submission for REP017 as “Gabriel/RegData”, wording that predates the completed move.

The FCA Handbook provides the REP017 form in SUP 16 Annex 27E, including the version dated 14 September 2019. The FCA also publishes an Excel template, but its current worksheet structure and sheet names should be verified directly before they are used as technical specifications. The FCA has documented XML specifications for RegData data items: its Data Reference Guides contain the XML specifications and the validations applied to data items submitted through RegData, and the FCA’s current RegData guidance directs firms to those guides. The presently accepted REP017 schema version and any file-naming restrictions should be checked in RegData before implementation; no specific schema version is stated here. For teams that pull Handbook text into their controls library, our guide to the FCA Handbook API shows how to query SUP provisions programmatically.

Resubmission is the correction route for the adjustments described in the deadlines section: the notes point providers to the resubmission facility made available through the electronic submission channel for REP017.

Late or incomplete filing carries a fixed cost. SUP 16.3.14R requires a firm that does not submit a complete report by its due date to pay an administrative fee of GBP 100, and SUP 16.13.3B applies that rule to payment service providers that must submit reports under SUP 16.13 and the PSRs. SUP 16.3.14AG adds that a failure to submit may also lead to a financial penalty and other disciplinary sanctions. Under SUP 16.3.15G, the FCA may send reminders when reports are overdue, and firms should not assume the FCA has received a report merely because no reminder arrived.

Validation of REP017: the RegData rules to confirm and the gaps between form and notes

The FCA Handbook form establishes REP017’s row-and-column reporting structure. The current RegData field-level validation rules, including mandatory-cell requirements and relationships between transaction and fraud figures, require confirmation against the REP017 Data Reference Guide before they are implemented as submission controls. In the same way, the FRN should be checked against the FCA-assigned six- or seven-digit identifier, and the H1/H2 selection should follow the reporting-period requirements applicable to the firm; the precise input-field restrictions must be confirmed against the current RegData REP017 specification.

The EBA guidelines add consistency rules the cell checks cannot see. Guideline 2.8 allocates each transaction to only one sub-category for each row of each breakdown, and Guideline 2.7 requires data that can be cross-referenced in line with the EBA’s Annex 2. Guideline 2.10 distinguishes zero, for no transactions, from “NA”, for a breakdown that does not apply to the provider. The FCA completion notes do not establish how that distinction is represented in the current REP017 submission fields. Whether RegData accepts “NA”, a blank entry or another representation must be checked against the live data-item validation specification before a missing-value rule is implemented.

The sources reviewed do not reproduce the RegData validation rule list or a catalogue of common rejection reasons for REP017. What the documents do expose is a set of internal inconsistencies that can send a preparer to the wrong cell:

• For an AIS fraud incident with no financial loss, the notes say to enter zero “at 214B” and explain the fraud “at 214C”; Table 2 on the form uses 209B and 209C.
• The notes ask the AISP to describe the fraud type with the highest total value; the form’s 209C header asks for descriptions of up to three fraud types, in order of highest loss.
• The notes list loss cells only up to 154A; the form also has loss rows 164 to 166 for cash withdrawals and 196 to 198 for e-money.
• The notes’ exemption list names six SCA exemptions; the form’s rows add “payment to self” and “contactless low value”.

The data definitions survive these slips intact, but a preparation workbook built from the notes alone will miss rows that the form requires.

Caveats and interactions: APP reimbursement data, SCA fraud rates and exemption rows

APP reimbursement data measures a different population

REP017’s manipulation-of-the-payer counts will not reconcile to a provider’s authorised push payment reimbursement figures, and they are not meant to. The Payment Systems Regulator’s Faster Payments reimbursement requirement runs through Specific Direction 20, and its policy statement PS24/3 requires in-scope sending providers to report compliance data monthly to Pay.UK. That data covers Faster Payments APP scams; REP017’s manipulation category spans more payment types, runs half-yearly and goes to the FCA. Our guide to SD20 reporting covers the Pay.UK side.

The receiving side is a further gap. Credit transfer fraud in REP017 belongs to the payer’s provider, so a receiving provider that identifies mule accounts does not report those inflows in the credit transfer section; the controls on that side are covered in our piece on the FCA money mule review.

The TRA fraud rate and REP017 use different numerators

The Approach Document draws the line explicitly. For the transaction risk analysis exemption, a provider’s fraud rate counts only the fraudulent transactions for which it was solely liable and leaves out transactions outside the scope of SCA, such as merchant-initiated transactions (paragraph 20.75). REP017 records fraud whoever bore the liability. At the same time, the FCA expects the transaction totals used for monitoring to be consistent with the totals reported under regulation 109 (paragraph 20.83). The practical reading: the transaction totals are expected to be consistent between the two, while the fraud counts can differ because of the liability and SCA-scope rules.

One exemption per fraudulent transaction, and rows that may not fit

A transaction may qualify for several SCA exemptions at once. For fraud reporting, the Approach Document requires each fraudulent transaction to be assigned to a specific exemption and reported under one exemption only. The completion notes quote this passage as paragraph 20.39 of the Approach Document; in the May 2026 version the same text sits at paragraph 20.43, so a cross-reference copied from the notes points to the wrong paragraph.

A harder question is fraud authenticated without SCA that fits none of the listed reasons. The EBA’s consolidated guidelines added “Merchant initiated transactions” and “Other” to the reasons for not applying SCA in the card and e-money breakdowns; the FCA’s 2019 form carries neither category among its reasons for not applying SCA, and the FCA notes do not say where such fraud goes. None of the FCA sources reviewed for this article answers the question.

Proportionality, waivers and losses

The only proportionality lever the directions contain is the annual frequency for small payment institutions, small e-money institutions and RAISPs. The sources reviewed describe no waiver or threshold below which a provider in a listed category may stop reporting. Losses also need care in any reconciliation: because the loss rows record the booked residual loss in the period it is booked, as a single figure unrelated to that period’s transactions, they will rarely match the fraud value columns of the same return.

Changes to REP017 since 2018 and the open questions in the 2026 payments reform

The return’s legal and form layers have each moved at different times. The dates below come from the legislation.gov.uk amendment notes, the Handbook version stamps and the FCA and EBA documents cited.

The July 2026 Treasury consultation is the item to track. It says the government is considering whether responsibility for setting certain requirements should be delegated to the FCA, and that where it decides to delegate, the requirements in the PSRs and the Electronic Money Regulations 2011 would be removed from the statute book, with the FCA able to consult on carrying over existing requirements or proposing changes. It also records the government’s commitment to commence revoking the PSRs’ strong customer authentication provisions so the FCA can make more outcomes-based authentication rules. The consultation does not mention regulation 109, fraud statistics or REP017. REP017’s SCA and exemption rows are built on the SCA technical standards’ categories, and neither the consultation nor any FCA document reviewed says what would happen to those rows.

The same consultation describes the Financial Services and Markets Bill 2026 as being considered by Parliament and proposing the consolidation of the Payment Systems Regulator into the FCA. That affects the APP reimbursement regime that sits beside REP017, while the REP017 directions sit in SUP 16.13 already.

One item on legislation.gov.uk is easy to misread. The page for regulation 109 lists an outstanding effect: a power to amend conferred by section 23 of the Financial Services Act 2021. Section 23 is a Treasury power to make provision about Gibraltar, and the PSRs are among the regulations it can touch. It is a power, and nothing on that page amends the reporting duty.

Frequently Asked Questions

A customer reports an unauthorised payment eleven months after it was executed. Where does it go?

The transaction belongs to the period in which it was executed, so the return for that earlier half-year needs adjusting; the notes direct the adjustment into the next reporting window through the resubmission facility. The loss is handled differently: the residual loss enters the loss rows of the period in which it is finally booked, so the transaction and its loss can land in different returns.

We are both the issuer and the acquirer of the same card payment. Do we report it twice?

EBA Guideline 2.11 requires card payments to be reported from both the payer’s and the payee’s provider perspectives, separately and with different breakdowns, and the FCA form gives each its own section. Neither the FCA notes nor the EBA text carves out transactions where one provider plays both roles. The better reading is that both sections are completed, with each recording the transaction from its own side; the sources do not address the point directly.

A fraudster made ten transfers from one compromised account. Is that one fraud or ten?

Ten. EBA Guideline 2.9 counts each payment transaction or fraudulent payment transaction in a series as one, so volume rises by ten and value by the sum of the ten amounts.

Do we report fraudulent payments that we blocked before execution?

No. The notes exclude transactions that were not executed and did not result in a transfer of funds, and EBA Guideline 2.4 states that prevented fraudulent transactions blocked before execution on suspicion of fraud are not included.

How are euro or dollar transactions converted for Table 1?

The FCA notes give a conversion rule only for Table 2, where AISPs use the average ECB reference rate for the period or, failing that, the average of the Bank of England’s daily spot rates. For Table 1 the notes require values in pounds sterling but state no method. The EBA guidelines, which the notes are read with, convert using the exchange rates applied to the transactions or the average ECB reference rate for the period (Guideline 2.3); applying that approach to Table 1 is an inference from the EBA text, and the choice is worth documenting in the return’s working papers.

Can the late-filing fee be waived?

SUP 16.3.14AG says that if it appears to the FCA that, in the exceptional circumstances of a particular case, payment of a fee would be inequitable, the FCA may reduce or remit all or part of it, with a cross-reference to FEES 2.3. The bar is “exceptional circumstances”, and the decision sits with the FCA.

Related Articles

• PSR Specific Direction 20: APP Scam Reimbursement Reporting: the Faster Payments reimbursement requirement and the compliance data sending providers report to Pay.UK.
• PSD2 Reporting Requirements for Payment Institutions: Complete Practitioner Guide: the fraud, statistical, prudential, incident and complaint reporting streams under PSD2.
• FCA Money Mule Review: Look Beyond the First Receiving Account: the FCA’s money mule review and the receiving-account controls it examines.
• FCA Handbook API: How to Query UK Rules Programmatically: retrieving SUP and other Handbook provisions in machine-readable form.
• FRIDA Scheme Rulebook: EPC Opens Fraud Data-Sharing Consultation: the European Payments Council’s consultation on a fraud data-sharing scheme rulebook.

Key Takeaways

• Map every in-scope FRN to one of the two SUP 16.13.8D calendars; a small PI, small EMI or RAISP files H1 and H2 together after year end.
• Build Table 1 in pounds sterling, with volumes as counts and values to two decimals (EBA Guideline 2.2), and confirm the remaining input restrictions against the current RegData data item.
• Assign ownership per leg before the period closes: payer’s provider for transfers, payee’s provider for direct debits, issuer and acquirer both for cards.
• Keep an adjustment log of late-detected fraud and cleared cases, keyed to execution period, and file it through the resubmission facility in the next window.
• Work from the form’s row list as well as the notes: loss rows 164 to 166 and 196 to 198, and the extra exemption rows, appear only on the form.
• Expect REP017 manipulation counts, SD20 Pay.UK data and the TRA fraud rate to differ; only the transaction totals used for SCA monitoring are expected to be consistent with REP017.
• Watch for FCA consultations that follow HM Treasury’s July 2026 payments consultation, particularly any that touch authentication rules and REP017’s SCA rows.

Sources and References

• The Payment Services Regulations 2017 (SI 2017/752), contents: legislation.gov.uk
• PSRs 2017, regulation 109 (Reporting requirements) with amendment notes: legislation.gov.uk
• PSRs 2017, regulation 2 (Interpretation: excluded provider, payment service provider): legislation.gov.uk
• Financial Services Act 2021, section 23 (Power to make provision about Gibraltar): legislation.gov.uk
• FCA Handbook, SUP 16.13 Reporting under the Payment Services Regulations: handbook.fca.org.uk
• FCA Handbook, SUP 16.3 General provisions on reporting (SUP 16.3.13R, 16.3.14R, 16.3.14AG, 16.3.15G): handbook.fca.org.uk
• FCA Handbook, SUP 16 Annex 27E REP017 Payments Fraud Report: handbook.fca.org.uk
• REP017 form, PDF version dated 14 September 2019: api-handbook.fca.org.uk
• FCA Handbook, SUP 16 Annex 27F Notes on completing REP017 Payments Fraud Report: handbook.fca.org.uk
• FCA Handbook, SUP 16 Annex 27H Notes on completing REP018 Operational and Security Risk form: handbook.fca.org.uk
• FCA, REP017 payments fraud report Excel template: fca.org.uk
• FCA, Payment Services and Electronic Money: Our Approach (May 2026, version 8): fca.org.uk
• FCA, All reporting firms moved to FCA’s new data collection platform RegData (19 May 2021): fca.org.uk
• FCA, RegData data reference guides (XML specifications and validations for RegData data items): fca.org.uk
• Bank of England, Changes to FCA Firm Reference Numbers (FRNs) and Product Reference Numbers (PRNs) (July 2023): bankofengland.co.uk
• EBA, Guidelines on reporting requirements for fraud data under Article 96(6) PSD2, EBA/GL/2018/05 (consolidated version): eba.europa.eu
• HM Treasury, Modernising Payment Services Regulation: Consultation (July 2026): assets.publishing.service.gov.uk
• Payment Systems Regulator, PS24/3 FPS APP scams reimbursement compliance and monitoring (July 2024): psr.org.uk

Before the Next REP017 Window Closes

A clean REP017 depends on decisions made before the half-year ends: which legal entity owns each leg, which exemption each non-SCA fraud is tagged to, and how late-detected cases are logged against their execution period. With those settled, the return itself is a cell-by-cell transfer onto the 2019 form, checked against the current RegData validation rules. The artifact to produce for each period is the completed return plus the adjustment log that feeds the next resubmission, filed through RegData within two months of 30 June or 31 December, or for annual filers both halves within two months of 31 December.

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.