Excel Sample Sheet 32696 | V Reports Quality Control Qc Documentation

Partial file snippet.

Sheet 1: QC_Cover page

QC documentation

Payment statistics (CDDP) quality control documentation

BCL Regulation 2021/30

Version 2022-05

Sheet 2: QC_General principles

Payment statistics quality control documentation - General principles

General
Principle
Item I
Item II
Description

GP01
Introduction
BCL quality controls policy
̶ Since 2012, our policy concerning the control of quality of the V-reports has been consisting in plausibility checks conducted per reporting agent and on a yearly basis.
̶ Automated quality checks realised on a monthly basis have been introduced in October 2018 in order to enhance the quality check process both for the BCL and for the reporting agent. These types of quality control bring significant added value, mainly in terms of timing: the reporting agent can immediately verify the data for the recent reference period and correct them, if necessary. Immediate corrections of the data prevent “flagging” the same issue in subsequent QC reports.

GP02
Introduction
Legal documents & reporting instructions
̶ All the documents of the BCL regulatory reporting relating to the collection of data on payment instruments and operations (the so-called CDDP or V-reports) can be found on our website: https://www.bcl.lu/en/payment-systems/Reporting/Instructions-de-reporting/index.html

In particular, the document “BCL manual on payment statistics” contains the structure of the reporting tables, as well as relevant codes.

GP03
Introduction
Contact details
̶ Please send your QC report replies or any relevant questions to market_infrastructures@bcl.lu.
̶ Please always include the CSSF Nosig number in the subject of your email (for example B001 or Z012). This helps us to keep track of all correspondence with you.
̶ Please inform us of any change in the contact details on your side so that we can update our distribution list accordingly.
- We always prefer a group email address (e.g. reporting@privatebank.lu) to a list of individual email adresses' (j.smith@privatebank.lu, j.doe@privatebank.lu, mary@privatebank.lu, etc)

GP04
Features of the QC report
Recipients of the QC report
̶ The QC report is sent monthly by email to the person(s) indicated as our contact person of the V-reports in your PSP.
Some controls are run every month, others every quarter.

GP05
Features of the QC report
Meaning of checks
̶ The presence of a QC sheet does not imply incorrectness of your data. Often, following your internal analysis, confirmation or explanation of the data is enough. This particularly holds for QC08 and QC08S (outlier analysis), where a business explanation often exists for an abrupt month-on-month movement. If the data flagged in a particular check are confirmed by you and re-approved by us, we can integrate that in the system to avoid flagging the same issue again in the following QC report.
̶ The QC exercise is also an opportunity to ensure the data are reported in accordance with the methodology and allows us to understand the payment activities of your PSP.

GP06
Features of the QC report
Format of the QC report
̶ The report is an Excel file, sent in an encrypted ZIP file. The password to unlock the ZIP file is different for each reporting agent and can be only communicated via telephone. In case you cannot open the ZIP file, for example due to local IT policy, please contact us.

GP07
Features of the QC report
Length of the checked time series
̶ For most checks, the QC report verifies data for the reference period and previous 12 months. For example, for reference period 2018-11, the report checks data between 2017-11 and 2018-11, inclusive. For the seasonal QC08, a longer time series is needed to correctly detect the seasonal variations (from 201401).

GP08
Features of the QC report
Timeline
̶ The QC report is normally sent within 2 months after the end of the reference period. For example, for reference period 201809, the QC report was sent in mid-November 2018.

GP09
Replies and data corrections
Format of replies
̶ There are several possible scenarios.
• If corrections are necessary: you may reply to the report by email (without including any sensitive data) or in the Excel report itself (and send it back in an encrypted ZIP file, using the same agreed password). You must however send the corrected data itself via the usual transmission channel such as SoFiE or eFile. Corrections by email cannot be accepted, for both legal and technical reasons.
• If corrections are not necessary: you may reply to the report by email, without including any sensitive data, or in the Excel report itself, and send it back to us in an encrypted ZIP file (in case you would like to comment on specific data), using the mutually agreed password.
̶ In any case, please always state the “Nosig” number in the subject of your email. Examples (fictive) of email subjects:
• B785 Monthly Quality Control (QC) report on payment statistics (2018-12)
• Z357 Monthly Quality Control (QC) report on payment statistics (2018-09)
̶ If replying to a QC report, it is enough to reply to the original email sent by us, which already includes the Nosig number of your institution.
̶ You may reply in English, French, or German.

GP10
Replies and data corrections
Deadline for replies
̶ Ideally, we would receive an answer to the report within 30 days after reception, i.e. before preparation of the QC report for the next reference period. However, we always welcome replies to previous QC reports, as well as corrections of historical data, at any moment.

Sheet 3: QC_Detailed description

Payment statistics quality control documentation - Detailed description of the QCs

N°
Quality
Control
Scope
(CDDP table)
Frequency (Monthly or Quarterly)
Volume / Value
Description I
Description II

QC01
V1.20
V1.21
V1.30
V1.31
V1.220
M
Volume + Value
Normally, if credit transfers or direct debits are reported, so should be the number of payment accounts (the opposite also holds true)
̶ In case the customer credit transfers (V1.20 or V1.21) or direct debits (V1.30 or V1.31) are reported, payment accounts should also be reported (V1.220), and vice versa.
̶ In some specific cases, only the payment transactions might be reported, without reporting V1.220. This is the case, for example, when only the PSP's own account operations are reported in V1.20. If your PSP does not offer payment accounts and you see this check, please contact us.

For V1.220, only payment accounts (PMAC) are considered in this check. Technical accounts (TMAC) are excluded.

QC02
ALL
M
Volume + Value
Volume and value are reported together and should be strictly positive
̶ This check helps discover swapped volume/value, negative values, or missing VOLU/VALE.
The data in this check are verified at the smallest detail (no aggregation by table), i.e. line by line.
̶ The data rows are flagged if at least one of the following conditions is met:
• Volume is positive and value is missing or zero
• Value is positive and volume is missing or zero
• Ratio volume/value is inferior to 2% (this includes cases where either volume or value is negative)

QC03
ALL - except:
V1.40
fraud tables
M
Volume
Gaps in data
̶ This check verifies the continuity of transmission of data. Data are aggregated by table and reference period.
̶ A table is flagged if, during the last 12 months, this table was not transmitted at least once or if it was transmitted empty. tables that were transmitted empty over the course of the last 12 months are not shown, as they might not be applicable for the given reporting PSP (e.g. a bank with no e-money activity will not report any data in the table V1.90 or V1.91). This control focuses on the gaps in transmission, from purely technical point of view, rather than on whether a table is applicable or not for a given reporting PSP.

QC04
n/a
n/a
n/a
This check is not implemented
n/a

QC05
n/a
n/a
n/a
This check is not implemented
n/a

QC06
n/a
n/a
n/a
This check is not implemented
n/a

QC07
n/a
n/a
n/a
This check is not implemented
n/a

QC08
Variable list of tables
M
Volume + Value
Check for outliers in the given time series
- Both QC08 and QC08S aggregate level at the “AggregationLevel”. For more details, see sheet “QC08(S) info” in your QC report.
̶ The point of this check is to look for outliers, or extreme differences from one month to another. The data are aggregated by table. In the QC report, the sheet “QC08 calc” contains the calculations, whereas the sheet “QC08 charts” shows the data in a chart. Normally, it is enough to have a look at the charts only, where either a sharp peak or a sharp fall in the last (reference) period is observed. The calculation sheet is included for completeness.
̶ Please find below the precise formula for the calculation, for your information only:

̶ If the StdDev ratio is higher than 2 in the reference period in question, the table is flagged.

QC08S
Variable list of tables
M
Volume + Value
Seasonal check for outliers in the given time series
Both QC08 and QC08S aggregate level at the “AggregationLevel”. For more details, see sheet “QC08(S) info” in your QC report.
The goal of this check is to detect extreme values, taking into account the annual seasonal variations.
Method used: Holt-Winter's exponential smoothing.
If the reported value in reference period is below the 'lower bound' or above the 'upper bound', it is flagged as an outlier.
Data used: from 201401 to the month preceding the reference period.
This method was first run in production in October 2020, for the reference period 2020-08.

QC09
n/a
n/a
n/a
This check is not implemented
n/a

QC10
n/a
n/a
n/a
This check is not implemented
n/a

QC11
V1.200
V1.50
M
Volume + Value
In case of card issuing activity, the stock of issued payment cards in table V1.200 should be reported along with card transactions (issuing) in table V1.50

QC12
V1.20, V1.20-F, V1.30, V1.30-F, V1.31, V1.40
M
Volume + Value
Comparison of payment schemes, currencies, and settlement channels
The following rules are checked:
* if payment scheme is in (SEPA, SCTI, SCOR, SB2B) then the currency must be EUR
* if settlement channel is in (TAR2, EUR1, STE1, STE2, TIPS, ERT1) then the currency must be EUR
* if settlement channel is STE2 then the payment scheme must be in (SEPA, SCOR, SB2B)

QC13
n/a
n/a
n/a
This check is not implemented
n/a

QC14
V1.91
M
Volume + Value
V1.91 country of the Electronic Money Scheme (EMS)
The debtor/creditor EMS should be LU, apart from some exceptions. Please contact us in case of doubt.

QC15
V1.50, V1.50-F, V1.52, V1.52-F
M
Volume + Value
Some types of cards are not expected
This control verifies entities that offer any of the following types of cards: MXCA, E1CA, ONCA, OTHR.
The other goal of this control is to monitor new types of cards offered by the reporting institutions.

QC16
ALL tables with country code splits
M
Volume + Value
Unexpected country codes
̶ In some cases, high percentage of XX (or other unexpected country codes) may signify a problem in data allocation or problem in the data source.
-The control is included in case the % of transactions with unexpected country codes exceeds 2% of the total
̶ Please contact us in case this control concerns your institution.

QC17
n/a
n/a
n/a
This check is not implemented
n/a

QC18
V1.200
V1.201
M
Value
The float should be present for all prepaid cards
* If prepaid or e-money cards are reported in V1.200/V1.201, a float is expected.
* conversely, float is not expected for other types of cards

QC19
n/a
n/a
n/a
This check is not implemented
n/a

QC20
n/a
n/a
n/a
This check is not implemented
n/a

QC21
ALL except
V1.200
V1.201
V1.220
M
Volume + Value
Same data in consecutive months
̶ This control checks whether the total for each table is the same in two or more consecutive months, above threshold=50. Tables for which the average month-on-month change < 20 are ignored (to exclude relatively stable tables, such as stocks of cards, ATMs, etc). Only data where both volume and value are constant are flagged.
̶ This check aims to uncover purely technical issues, such as duplicate transmissions from one month to another (i.e. same data sent to the BCL twice in a row, for two reference periods).
̶ Data are aggregated by table.

QC22
n/a
n/a
n/a
This check is not implemented
n/a

QC23
V1.20
V1.21
Q
Volume + Value
Equality of on-us transactions in tables

̶ For most reporting PSPs, in case of credit transfers, where settlement channel='on-us', the total of sent (i.e. V1.20) credit transfers should be equal to the total of received (V1.21) credit transfers. The on-us transactions should be reported in both tables, with the same value and volume.
̶ Some exceptions are possible, such as when a payment is sent to (or received on) an account that is not a payment account (e.g. savings account, mortgage or loan account, etc.). In other words, if your institution offers other than payment accounts, the totals for V1.20 and V1.21 should not be equal and this check is irrelevant. Please contact us if this concerns your institution.
̶ Rule: Flag if the difference between sent/received on-us CTs is larger than 1.5%, or if either table is missing.

QC24
V1.20
V1.21
Q
Volume + Value
By default, all credit transfers, where settlement channel='on-us', should be domestic, i.e. sent to or received from LU
̶ This QC will possibly concern other tables in the future

QC25
n/a
n/a
n/a
This check is not implemented
n/a

QC26
V1.20
V1.41
V1.42
Q
Volume
Comparison of CDDP and Target2 volume data
-- We compare volume data from CDDP tables (reported by the reporting PSP) with transaction data retrieved by us from Target2 system.
-- For all CDDP tables, data are filtered on settlement channel = TAR2.
-- Only sent transactions (outflows) are compared.
-- For Target2, the total for Swift messages MT103, MT202, and MT204 is shown.
-- Only direct participants in Target2 are concerned by this control.
-- Please note that small differences (0.5%-10%) are expected, as some types of transactions are not reported in CDDP. In this case we do not expect any action from the reporting PSP.
-- Only large differences are subject to review.

QC27
V1.50
V1.51
M
Volume
Difference V1.50 and V1.51
The table V1.51 should not deviate much from table V1.50 (where operation type = Sales).
Data are aggregated on initiation sub-channel and the country of terminal.
Missing table, or differences of more than 15% are flagged.

QC28
n/a
n/a
n/a
This check is not implemented
n/a

QC29
V1.90
V1.91
V1.91-F
M
Volume
E-money reported by payment institutions
Only credit institutions and e-money institutions may offer e-money.
If your payment institution reports e-money, please contact the BCL.

QC30
n/a
n/a
n/a
This check is not implemented
n/a

QC31
n/a
n/a
n/a
This check is not implemented
n/a

QC32
n/a
n/a
n/a
This check is not implemented
n/a

QC33
V1.222
V1.230
M
Volume
AISP: number of accessed accounts, number of clients
Tables V1.222 (PSP type = AISP) and V1.230 (PSP type = AISP) should be transmitted together. Flag if either table is missing.

The words contained in this file might help you see if this file matches what you are looking for:

...Sheet qc cover page documentation payment statistics cddp quality control bcl regulation version general principles generalprinciple item i ii description gp introduction controls policy since our concerning the of vreports has been consisting in plausibility checks conducted per reporting agent and on a yearly basis automated realised monthly have introduced october order to enhance check process both for these types bring significant added value mainly terms timing can immediately verify data recent reference period correct them if necessary immediate corrections prevent ldquo flagging rdquo same issue subsequent reports legal documents amp instructions all regulatory relating collection instruments operations socalled or be found website httpswwwbclluenpaymentsystemsreportinginstructionsdereportingindexhtmlin particular document manual contains structure tables as well relevant codes contact details please send your report replies any questions market infrastructures bcllu always in...

Related files

Share

Help

Payment statistics quality control documentation - General principles

General Principle	Item I	Item II	Description
GP01	Introduction	BCL quality controls policy	̶ Since 2012, our policy concerning the control of quality of the V-reports has been consisting in plausibility checks conducted per reporting agent and on a yearly basis. ̶ Automated quality checks realised on a monthly basis have been introduced in October 2018 in order to enhance the quality check process both for the BCL and for the reporting agent. These types of quality control bring significant added value, mainly in terms of timing: the reporting agent can immediately verify the data for the recent reference period and correct them, if necessary. Immediate corrections of the data prevent “flagging” the same issue in subsequent QC reports.
GP02	Introduction	Legal documents & reporting instructions	̶ All the documents of the BCL regulatory reporting relating to the collection of data on payment instruments and operations (the so-called CDDP or V-reports) can be found on our website: https://www.bcl.lu/en/payment-systems/Reporting/Instructions-de-reporting/index.html In particular, the document “BCL manual on payment statistics” contains the structure of the reporting tables, as well as relevant codes.
GP03	Introduction	Contact details	̶ Please send your QC report replies or any relevant questions to market_infrastructures@bcl.lu. ̶ Please always include the CSSF Nosig number in the subject of your email (for example B001 or Z012). This helps us to keep track of all correspondence with you. ̶ Please inform us of any change in the contact details on your side so that we can update our distribution list accordingly. - We always prefer a group email address (e.g. reporting@privatebank.lu) to a list of individual email adresses' (j.smith@privatebank.lu, j.doe@privatebank.lu, mary@privatebank.lu, etc)
GP04	Features of the QC report	Recipients of the QC report	̶ The QC report is sent monthly by email to the person(s) indicated as our contact person of the V-reports in your PSP. Some controls are run every month, others every quarter.
GP05	Features of the QC report	Meaning of checks	̶ The presence of a QC sheet does not imply incorrectness of your data. Often, following your internal analysis, confirmation or explanation of the data is enough. This particularly holds for QC08 and QC08S (outlier analysis), where a business explanation often exists for an abrupt month-on-month movement. If the data flagged in a particular check are confirmed by you and re-approved by us, we can integrate that in the system to avoid flagging the same issue again in the following QC report. ̶ The QC exercise is also an opportunity to ensure the data are reported in accordance with the methodology and allows us to understand the payment activities of your PSP.
GP06	Features of the QC report	Format of the QC report	̶ The report is an Excel file, sent in an encrypted ZIP file. The password to unlock the ZIP file is different for each reporting agent and can be only communicated via telephone. In case you cannot open the ZIP file, for example due to local IT policy, please contact us.
GP07	Features of the QC report	Length of the checked time series	̶ For most checks, the QC report verifies data for the reference period and previous 12 months. For example, for reference period 2018-11, the report checks data between 2017-11 and 2018-11, inclusive. For the seasonal QC08, a longer time series is needed to correctly detect the seasonal variations (from 201401).
GP08	Features of the QC report	Timeline	̶ The QC report is normally sent within 2 months after the end of the reference period. For example, for reference period 201809, the QC report was sent in mid-November 2018.
GP09	Replies and data corrections	Format of replies	̶ There are several possible scenarios. • If corrections are necessary: you may reply to the report by email (without including any sensitive data) or in the Excel report itself (and send it back in an encrypted ZIP file, using the same agreed password). You must however send the corrected data itself via the usual transmission channel such as SoFiE or eFile. Corrections by email cannot be accepted, for both legal and technical reasons. • If corrections are not necessary: you may reply to the report by email, without including any sensitive data, or in the Excel report itself, and send it back to us in an encrypted ZIP file (in case you would like to comment on specific data), using the mutually agreed password. ̶ In any case, please always state the “Nosig” number in the subject of your email. Examples (fictive) of email subjects: • B785 Monthly Quality Control (QC) report on payment statistics (2018-12) • Z357 Monthly Quality Control (QC) report on payment statistics (2018-09) ̶ If replying to a QC report, it is enough to reply to the original email sent by us, which already includes the Nosig number of your institution. ̶ You may reply in English, French, or German.
GP10	Replies and data corrections	Deadline for replies	̶ Ideally, we would receive an answer to the report within 30 days after reception, i.e. before preparation of the QC report for the next reference period. However, we always welcome replies to previous QC reports, as well as corrections of historical data, at any moment.

Payment statistics quality control documentation - Detailed description of the QCs

N° Quality Control	Scope (CDDP table)	Frequency (Monthly or Quarterly)	Volume / Value	Description I	Description II
QC01	V1.20 V1.21 V1.30 V1.31 V1.220	M	Volume + Value	Normally, if credit transfers or direct debits are reported, so should be the number of payment accounts (the opposite also holds true)	̶ In case the customer credit transfers (V1.20 or V1.21) or direct debits (V1.30 or V1.31) are reported, payment accounts should also be reported (V1.220), and vice versa. ̶ In some specific cases, only the payment transactions might be reported, without reporting V1.220. This is the case, for example, when only the PSP's own account operations are reported in V1.20. If your PSP does not offer payment accounts and you see this check, please contact us. For V1.220, only payment accounts (PMAC) are considered in this check. Technical accounts (TMAC) are excluded.
QC02	ALL	M	Volume + Value	Volume and value are reported together and should be strictly positive	̶ This check helps discover swapped volume/value, negative values, or missing VOLU/VALE. The data in this check are verified at the smallest detail (no aggregation by table), i.e. line by line. ̶ The data rows are flagged if at least one of the following conditions is met: • Volume is positive and value is missing or zero • Value is positive and volume is missing or zero • Ratio volume/value is inferior to 2% (this includes cases where either volume or value is negative)
QC03	ALL - except: V1.40 fraud tables	M	Volume	Gaps in data	̶ This check verifies the continuity of transmission of data. Data are aggregated by table and reference period. ̶ A table is flagged if, during the last 12 months, this table was not transmitted at least once or if it was transmitted empty. tables that were transmitted empty over the course of the last 12 months are not shown, as they might not be applicable for the given reporting PSP (e.g. a bank with no e-money activity will not report any data in the table V1.90 or V1.91). This control focuses on the gaps in transmission, from purely technical point of view, rather than on whether a table is applicable or not for a given reporting PSP.
QC04	n/a	n/a	n/a	This check is not implemented	n/a
QC05	n/a	n/a	n/a	This check is not implemented	n/a
QC06	n/a	n/a	n/a	This check is not implemented	n/a
QC07	n/a	n/a	n/a	This check is not implemented	n/a
QC08	Variable list of tables	M	Volume + Value	Check for outliers in the given time series	- Both QC08 and QC08S aggregate level at the “AggregationLevel”. For more details, see sheet “QC08(S) info” in your QC report. ̶ The point of this check is to look for outliers, or extreme differences from one month to another. The data are aggregated by table. In the QC report, the sheet “QC08 calc” contains the calculations, whereas the sheet “QC08 charts” shows the data in a chart. Normally, it is enough to have a look at the charts only, where either a sharp peak or a sharp fall in the last (reference) period is observed. The calculation sheet is included for completeness. ̶ Please find below the precise formula for the calculation, for your information only: ̶ If the StdDev ratio is higher than 2 in the reference period in question, the table is flagged.
QC08S	Variable list of tables	M	Volume + Value	Seasonal check for outliers in the given time series	Both QC08 and QC08S aggregate level at the “AggregationLevel”. For more details, see sheet “QC08(S) info” in your QC report. The goal of this check is to detect extreme values, taking into account the annual seasonal variations. Method used: Holt-Winter's exponential smoothing. If the reported value in reference period is below the 'lower bound' or above the 'upper bound', it is flagged as an outlier. Data used: from 201401 to the month preceding the reference period. This method was first run in production in October 2020, for the reference period 2020-08.
QC09	n/a	n/a	n/a	This check is not implemented	n/a
QC10	n/a	n/a	n/a	This check is not implemented	n/a
QC11	V1.200 V1.50	M	Volume + Value	In case of card issuing activity, the stock of issued payment cards in table V1.200 should be reported along with card transactions (issuing) in table V1.50
QC12	V1.20, V1.20-F, V1.30, V1.30-F, V1.31, V1.40	M	Volume + Value	Comparison of payment schemes, currencies, and settlement channels	The following rules are checked: * if payment scheme is in (SEPA, SCTI, SCOR, SB2B) then the currency must be EUR * if settlement channel is in (TAR2, EUR1, STE1, STE2, TIPS, ERT1) then the currency must be EUR * if settlement channel is STE2 then the payment scheme must be in (SEPA, SCOR, SB2B)
QC13	n/a	n/a	n/a	This check is not implemented	n/a
QC14	V1.91	M	Volume + Value	V1.91 country of the Electronic Money Scheme (EMS)	The debtor/creditor EMS should be LU, apart from some exceptions. Please contact us in case of doubt.
QC15	V1.50, V1.50-F, V1.52, V1.52-F	M	Volume + Value	Some types of cards are not expected	This control verifies entities that offer any of the following types of cards: MXCA, E1CA, ONCA, OTHR. The other goal of this control is to monitor new types of cards offered by the reporting institutions.
QC16	ALL tables with country code splits	M	Volume + Value	Unexpected country codes	̶ In some cases, high percentage of XX (or other unexpected country codes) may signify a problem in data allocation or problem in the data source. -The control is included in case the % of transactions with unexpected country codes exceeds 2% of the total ̶ Please contact us in case this control concerns your institution.
QC17	n/a	n/a	n/a	This check is not implemented	n/a
QC18	V1.200 V1.201	M	Value	The float should be present for all prepaid cards	* If prepaid or e-money cards are reported in V1.200/V1.201, a float is expected. * conversely, float is not expected for other types of cards
QC19	n/a	n/a	n/a	This check is not implemented	n/a
QC20	n/a	n/a	n/a	This check is not implemented	n/a
QC21	ALL except V1.200 V1.201 V1.220	M	Volume + Value	Same data in consecutive months	̶ This control checks whether the total for each table is the same in two or more consecutive months, above threshold=50. Tables for which the average month-on-month change < 20 are ignored (to exclude relatively stable tables, such as stocks of cards, ATMs, etc). Only data where both volume and value are constant are flagged. ̶ This check aims to uncover purely technical issues, such as duplicate transmissions from one month to another (i.e. same data sent to the BCL twice in a row, for two reference periods). ̶ Data are aggregated by table.
QC22	n/a	n/a	n/a	This check is not implemented	n/a
QC23	V1.20 V1.21	Q	Volume + Value	Equality of on-us transactions in tables	̶ For most reporting PSPs, in case of credit transfers, where settlement channel='on-us', the total of sent (i.e. V1.20) credit transfers should be equal to the total of received (V1.21) credit transfers. The on-us transactions should be reported in both tables, with the same value and volume. ̶ Some exceptions are possible, such as when a payment is sent to (or received on) an account that is not a payment account (e.g. savings account, mortgage or loan account, etc.). In other words, if your institution offers other than payment accounts, the totals for V1.20 and V1.21 should not be equal and this check is irrelevant. Please contact us if this concerns your institution. ̶ Rule: Flag if the difference between sent/received on-us CTs is larger than 1.5%, or if either table is missing.
QC24	V1.20 V1.21	Q	Volume + Value	By default, all credit transfers, where settlement channel='on-us', should be domestic, i.e. sent to or received from LU	̶ This QC will possibly concern other tables in the future
QC25	n/a	n/a	n/a	This check is not implemented	n/a
QC26	V1.20 V1.41 V1.42	Q	Volume	Comparison of CDDP and Target2 volume data	-- We compare volume data from CDDP tables (reported by the reporting PSP) with transaction data retrieved by us from Target2 system. -- For all CDDP tables, data are filtered on settlement channel = TAR2. -- Only sent transactions (outflows) are compared. -- For Target2, the total for Swift messages MT103, MT202, and MT204 is shown. -- Only direct participants in Target2 are concerned by this control. -- Please note that small differences (0.5%-10%) are expected, as some types of transactions are not reported in CDDP. In this case we do not expect any action from the reporting PSP. -- Only large differences are subject to review.
QC27	V1.50 V1.51	M	Volume	Difference V1.50 and V1.51	The table V1.51 should not deviate much from table V1.50 (where operation type = Sales). Data are aggregated on initiation sub-channel and the country of terminal. Missing table, or differences of more than 15% are flagged.
QC28	n/a	n/a	n/a	This check is not implemented	n/a
QC29	V1.90 V1.91 V1.91-F	M	Volume	E-money reported by payment institutions	Only credit institutions and e-money institutions may offer e-money. If your payment institution reports e-money, please contact the BCL.
QC30	n/a	n/a	n/a	This check is not implemented	n/a
QC31	n/a	n/a	n/a	This check is not implemented	n/a
QC32	n/a	n/a	n/a	This check is not implemented	n/a
QC33	V1.222 V1.230	M	Volume	AISP: number of accessed accounts, number of clients	Tables V1.222 (PSP type = AISP) and V1.230 (PSP type = AISP) should be transmitted together. Flag if either table is missing.

Related files

Share

Share to social media

Help

Login Area