Data Sharing Community
The Single Business Partner Lookup now allows for just searching with country and global identifiers such as the DUNS and the Legal Entity Identifier (LEI). This removes the restriction on being able to just make use of local identifiers (e.g. domestic company registration numbers) in the context of the App.
Batch lookup of bank account trust scores (15 April 2021)
Enables a batch bank account lookup in the CDQ Community Bank Data Pool and the retrieval of the bank account's trust score. The results are provided in form of an excel report. The lookup result contains no information in case the respective bank account is not contained in the database. If the bank account is maintained then the result contains information about the bank account trust score, payment information, bank account details as well as the bank account owner information.
FIPS codes for US counties (14 April 2021)
FIPS codes are numbers which uniquely identify geographic areas in the United States. State-level FIPS codes have two digits, county-level FIPS codes have five digits of which the first two are the FIPS code of the state to which the county belongs. The CDQ Address Cleansing Services now support the enrichment of FIPS codes on region and county level. One typcial use case for getting to know the FIPS code of a business partner's location is the identification of tax jurisdictions, respectively the corresponding tax rates that are applied.... further results
Business partner data management is heavily redundant: Many companies manage data for the same entities such as country names and codes, bill-to, ship-to, and ordering addresses, or legal hierarchies of customers and suppliers. The CDQ collaboration approach is based on a trusted network of user companies that share and collaborativelay maintain this data.
An important prerequisite for collaborative data management is a common understanding of the shared data. For the CDQ Data Sharing Community, this common understanding is specified by the CDQ Data Model. The concepts of this model are defined and documented in this wiki which can be used as a business vocabulary. Moreover, the wiki provides a machine-readable interface to reuse this metadata by using semantic annotations.
A procedure is a common standard or "how-to" for a specific data management task. Within the CDQ Data Sharing Community, companies agree on such procedures to ensure similar rules and guidelines for similar tasks. For several countries, the CDQ Wiki provides such information, e.g. data quality rules, trusted information sources, legal forms, or tax numbers. Try
or select another country from the list.
From an integration perspective, CDQ web services are the most important component of the CDQ infrastructure. They provide the technical link between your business applications and the CDQ cloud services. We follow the REST design principle for web services which allows for lightweight interface design and easy integration. Of course, all web services are also available at WSDL interfaces.
Transformation of human-documented data requirements into executable data quality rules is mostly a manual IT effort. Changing requirements cause IT efforts again and again. Some checks, e.g. tax number validity (not just format!), require external services. Other checks, e.g. validity of legal forms, require managed reference data (e.g. legal forms by country, plus abbreviations). Continuous data quality assurance (i.e. batch analyses) and real-time checks in workflows often use different rule sets. Data requirements and related reference data are collected and updated collaboratively by the Data Sharing Community. Data quality rules are derived from these requirements automatically, auditor approved. All data quality rules are executed behind 1 interface, in real-time, 1’000+ rules in < 1s. Batch jobs and single-record checks use the same rule set and can be integrated by APIs. If reference data (e.g. correct tax numbers) is available, fix proposals are provided for incorrect records.
Companies are facing an ever increasing number of digitized frauds, meanwhile on a very professional level. Among other types, falsified invoices are causing significant financial damage, in some cases more than 1 Mio. USD by just one attack. One critical challenge to uncover those fraud attacks is to identify bank accounts (e.g. given by an invoice) which are not owned by the declared business partner (e.g. the supplier of an invoice) but by a third party, i.e. the attacker. The CDQ Data Sharing community is addressing this challenge by sharing information on known fraud cases and on proven bank accounts. The Fraud Case Database comprises known fraud cases, shared by community members. Other members can lookup these cases by bank account data (e.g. IBAN) to automate screening for critical accounts. On the other hand, the Whitelist comprises bank accounts which are declared "save" by community members. You can lookup shared Trust Scores to check a new bank account and to ensure that this account is already used by another member.