This guide explains how you can securely upload either an unconsolidated payment extract (e.g., SAP REGUH file) or a consolidated payment summary into your private Bank Account Storage within CDQ.
If you want to upload your payment file using the API, please refer to this guide.
The primary purpose of this upload is to enable your organization to protect itself against payment fraud. By storing, structuring, and analyzing your outgoing payment transactions, CDQ’s Fraud Prevention Services—including the Trust Score—help you evaluate the bank accounts you're paying to and avoid sending money to fraudulent accounts.
Your uploaded payment data—whether unconsolidated or consolidated—becomes the basis for:
- Identifying previously used and reliable beneficiary bank accounts
- Recognizing suspicious or unverified accounts
- Enhancing CDQ's Trust Score and alerting mechanisms
- Strengthening your internal controls before each payment run
In addition, your anonymized data contributes to the broader CDQ Data Sharing Community, improving fraud prevention insights across participating organizations—including yours.
Learning Goals
In this tutorial, you will learn how to:
- Prepare unconsolidated and consolidated payment files for upload
- Understand the differences and requirements for each file type
- Use the CDQ Cloud Apps to upload your payment file
Check your CDQ apps account.
- Log into the CDQ Cloud Apps
No account?
- If your organization is already a CDQ customer, ask your internal point of contact to create a CDQ dedicated account or request account. Account detail will be sent by email.
- If your organization is not yet a CDQ customer, please contact us to get started.
There are two types of payment files that CDQ supports for fraud prevention and bank account monitoring:
- Unconsolidated Payment Files – These contain individual transaction records (e.g.,
SAP REGUHextract). Each row reflects a single payment made to a bank account. This is the preferred approach due to its precision and flexibility. - Consolidated Payment Files – These are pre-aggregated on the level of a bank account and summarize payment relationships. While still useful, consolidated files must meet several specific preparation requirements.
| Aspect | Unconsolidated Files (e.g., REGUH) | Consolidated Files |
|---|---|---|
| Content | Individual payments to bank accounts | Aggregated history per bank account |
| Preferred? | Yes | Use only if no transactional data is available |
| Data Freshness Filtering | Performed automatically by CDQ | Must be done by you before upload |
| First / Last Payment Dates | Optional (can be derived) | Mandatory (must be included) |
| Inclusion in Fraud Pool | All rows processed | Rows without last payment date are excluded |
If you decide to submit a consolidated file, please ensure you:
- Filter your data: Only include payments made between 90 days ago and 2 years ago. CDQ cannot filter consolidated data.
- Include time range: Both the first payment date and last payment date to the payee must be provided.
- Avoid missing values: Records without a valid last payment date will not be considered for Fraud Prevention scoring and will only be stored in your private Bank Account Storage.
The table below describes the required structure for your CSV file. The Payment System Field column refers to the field names in your source system (also called sourceAttributes), while the CDQ Field column indicates the corresponding field names expected by CDQ (also called targetAttributes). Ensure your file maps each source field to the correct CDQ field as specified.
| # | Payment System Field | CDQ Field | Description | REGUH Import |
|---|---|---|---|---|
| 1 | ziban | internationalBankAccountIdentifier | IBAN of the account used in the transaction | Mandatory |
| 2 | zbnkn | nationalBankAccountIdentifier | National-format account number | Mandatory |
| 3 | zswif | bank.internationalBankIdentifier | SWIFT/BIC of the executing/receiving bank | Mandatory |
| 4 | zbnkl | bank.nationalBankIdentifier | National bank code (e.g., BLZ, Sort Code) | Mandatory |
| 5 | zbnks | bank.address.country.shortName | Country of the bank (e.g., DE, FR in ISO 3166-2-format) | Mandatory |
| 6 | zaldt | vendorPaymentSummary.lastPaymentDate | Most recent payment date to this payee (format: yyyy-MM-dd, e.g., 2024-07-15) | Mandatory |
| 7 | first_zaldt | vendorPaymentSummary.firstPaymentDate | First recorded payment date to this payee (format: yyyy-MM-dd, e.g.,2024-07-15) | Not used in REGUH import |
| 8 | name1 | payees[0].name | Name of the payee | Mandatory |
| 9 | nop | vendorPaymentSummary.numberOfPayments | Total number of payments made to this payee | Not used in REGUH import |
Each row in your CSV represents either a single payment (in the case of unconsolidated files) or a summary of historical transactions with a bank account (in the case of consolidated files). Both structures are supported by CDQ.
If required fields are missing or misnamed, the import will not proceed. Fields marked as 'Not used in REGUH import' are instead used for the import of consolidated data (formerly referred to as "whitelist import").
To upload your payment file, follow these steps:
- Ensure your account has either the Data Mirror App User or Data Mirror App Manager role assigned.
- Navigate to the Data Mirror Management app.
- Go to the Bank Account Data Mirror tab.
To import your payment file:
- Click the Import Data button. A modal window will appear.
- In the Data Transformation dropdown, select the file structure:
- Transactions (previously called Unconsolidated Payment Files): Contains individual transaction records (e.g., SAP REGUH extract). Each row reflects a single payment made to a bank account. This is the preferred approach due to its precision and flexibility.
- Consolidated Accounts (previously called Consolidated Payment Files): Pre-aggregated at the bank account level and summarizes payment relationships. Consolidated files must meet specific preparation requirements.
- Optionally, enable one of the following feature toggles to control the import:
- CLEAR_STORAGE: Clears all previously imported data from your Bank Account Storage before importing the new file. Use with caution, as this removes all historic data. Only one feature toggle should be used at a time.
- MERGE_PAYMENTS: (Default) Consolidates transaction records into existing bank account entries, merging multiple payments into a single aggregated view. Does not delete existing entries and preserves historical data. Only one feature toggle should be used at a time.
- Click the Start Import button to begin the import process.
The diagram below illustrates the full process of uploading either unconsolidated (preferred) or consolidated payment files to CDQ. It highlights:
- The initial decision point: whether you’re uploading detailed payment records or a pre-aggregated summary.
- Specific requirements for each file type:
- Unconsolidated: Each row is a payment; no manual filtering needed.
- Consolidated: Must exclude payments <90 days or >2 years old and must contain both first and last payment dates.
- A unified upload and import workflow for both file types:
- Step-by-step: Register → Upload → Trigger Import → (optional) Status Check.
- The effect of feature toggles:
- MERGE_PAYMENTS (default): Adds to existing data.
- CLEAR_STORAGE: Replaces all existing entries — use with caution!
This diagram helps clarify each action, its conditions, and its outcome, reducing the risk of missteps.
| Step | What You Do | What Happens |
|---|---|---|
| Step 1 | Export unconsolidated payment data and format as CSV | You prepare your unconsolidated data file (preferred method) |
| Step 1 (alt.) | Export consolidated payment data and format as CSV | You prepare a pre-aggregated account-level summary for upload |
| Step 2 | Sign in to Cloud Apps and go to Data Mirror Management App/ Bank Account Data Mirror Tab | You will be in a place that provide you possibility to manage you Bank Account Storage |
| Step 3 | Upload file | File is stored safely in you local Bank Account Storage |
Once uploaded, the payment data is stored in the CDQ Bank Account Data Mirror, which can be accessed via the CDQ Cloud Apps under this link.
The Bank Account Data Mirror is automatically created for your organization.
- Sharing is enabled by default.
- Sharing applies to the entire storage, not on a record-level.
- If desired, you can disable sharing under the "Edit Bank Account Data Mirror" menu in the app.
Disabling sharing means that your uploaded payment information will only be used internally and not contributed to the CDQ Data Sharing Community. Records once shared cannot be removed from the Sharing Pool.
This process is essential to protect your organization against payment fraud. Uploading your payment data gives you the ability to:
- Evaluate the trustworthiness of payee accounts
- Avoid payments to risky or previously unseen accounts
- Identify accounts that lack positive payment history
- Receive real-time support from CDQ’s Trust Score and fraud prevention tools
By securely uploading your transaction history, you gain transparency over your payment behavior and activate intelligent services that help you avoid financial losses.
And while your anonymized data also contributes to the CDQ Data Sharing Community, the primary value is for you—to reduce your exposure to fraud, proactively safeguard your payment operations, and increase trust in your daily financial processes.
We are constantly working on providing an outstanding user experience with our products. Please share your opinion about this tutorial!