Much is being written about and reported on the topic of supply chain compliance, whether this be the German Lieferkettensorgfaltspflichtengesetz (LkSG/Supply Chain Act), the corresponding EU directive that is in preparation, or the extraterritorial laws that have been valid internationally for some time and also affect the supply chain such as the UK Bribery Act (UKBA) or the US Foreign Corrupt Practices Act (FCPA). My colleagues have already addressed the content of the individual guidelines as well as the broader context on bribery, corruption and ESG and have published this in other blog posts. [👉Pinar Karacinar-Gehweiler: Compliance Requirements Due to the German Supply Chain Due Diligence Act; 👉Lea Ilina: ESG in the Tension Field of Corruption]. This blog post now outlines a corresponding IT system to support supply chain compliance and shows which components should be part of such a system, how and why.

Even if the above-mentioned regulations seem to have little in common at first glance, they all have at least the following points in common:

• Risk Analysis: The basis for compliance with the regulations is the creation of a company-specific risk analysis covering, among other things, vendors, their relationship to your own company, regions, products and services, contract types and other risk objects. It seems beneficial to initially create this risk analysis for all regulations, if this has not already been done, or to expand the existing risk analysis accordingly.
• Vendor Screening: The most obvious part of a supply chain compliance system is the "Know Your Customer" (KYC) screening of vendors. This part is referred to differently on the market: KYV (“Know Your Vendor“), KYBP (“Know Your Business Partner“), etc. We like to translate the "C" as Counterpart and can get by with the KYC principle without any problems. Apart from the confusion of terms, the point here is to know the business partner per se and the relevant actors of the partner, if any, and to check against relevant lists. In addition to sanctions lists, PEP lists (PEP = Politically Exposed Persons) and other information such as negative news ("Adverse Media") must also be used. Here, three levels need to be considered: Identity screening, integrity screening, and specific risk screening against the risks identified in the risk analysis. This screening takes place initially when the request/decision is made as to whether a business relationship can/may/should be entered into, as well as on an ongoing and risk-based basis.

This results in the following process view on the topic:

Fig. 1: Process view business partner screening

Combining the topics outlined above enables efficiency and productivity benefits to be leveraged. This makes it possible to create a uniform system for business partner compliance that covers and presents the relevant company-specific risks in a holistic manner. In addition to transparency benefits, this results above all in the avoidance of redundancy in processing both within the company and on the part of the business partner, i.e. the vendor. The support provided by a flexible IT system, called a supply chain compliance solution for simplicity’s sake, further contributes to cost reduction by avoiding IT silos, redundant data preparation and storage, and reducing other direct and indirect costs of such a software solution compared to multiple stand-alone solutions.

Based on the above considerations in connection with the process-related view of a business partner lifecycle, the following schematic structure results for the construction of such a flexible software solution, starting with the core processes:

• Identity Check (Check of business partner master data): In addition to the legal name and address, for example members of the governing bodies (managing directors, advisory boards, executive boards, etc.) and ownership structure (keyword: beneficial owner) need to be recorded. This information plays an important role in the automatic further processing for various reasons. This check needs to be conducted during the on-boarding process but also for continuous monitoring. As the process name suggests, this involves establishing the identity of the business partner in all its aspects. Connections to credit agencies and intermediaries, such as Dun & Bradstreet or similar, can increase the level of automation. The use of flexible, dynamic, digital questionnaires can also have a positive impact on efficiency. They help reduce redundancies and can be used as a self-service component in the bidding process, for example.
• Integrity Check (Check of identified master data of business partners against a number of lists (direct as well as indirect/sectoral sanctions, PEP, companies with bad press/unfriendly media, etc.)): This list set is different from the one used for identity check. Typically, compliance-specific lists are used here. Of course, in the area of sanctions management, it is also possible to work with the publicly provided lists of the EU, USA, UK and, for example, the World Bank. However, in the context of a make-or-buy consideration, both the expense and the risks of data management must be taken into account. In addition to the check during onboarding of a business partner, integrity must also be checked continuously, as the associated risk can change constantly.
• Specific Risk Check: To check the extended data of business partners for relationship risks with regard to regulatory aspects (non-operational risks), rules derived from the risk analysis are defined, which can then give rise to so-called "red flags", i.e. risk-relevant facts that need to be assessed and processed. It is advisable to perform this check during the onboarding of the business partner and to review it periodically on the basis of the risk rating after the decision to enter into a business relationship has been made. It is also advisable to be able to design the risk model flexibly. On the one hand, this means the possibility of defining additional checking rules as required - preferably by the relevant department - and, on the other hand, of making changes to the risk scoring model. A risk scoring model with dominant risks has proven to be both effective and efficient here. The digital questionnaire component already mentioned has also proven advantageous in the past, as long as it can be flexible in its structure and dynamically interactive in its responses.
• Event & Transaction Check: The event and transaction check can be implemented at different levels of complexity. In addition to some standard checks for high-risk transactions, it is also possible, for example, to work here on the basis of a fraud prevention system already in use. Even though this is not recommended, this area is often given lower priority in a software-based solution. This has not least to do with the complexity of the matter in connection with the implemented process reality in companies and in their ERP systems. This check is therefore often outsourced transaction-specifically per company directive to the so-called "first line of defense" (operational controls) and "third line of defense" (internal audit) as well as whistleblower systems and supported secondarily by means of IT. However, artificial intelligence and process mining functionalities offer new, highly efficient IT support and automation options that can significantly reduce the risk of bribery and corruption in this area.
• Case Management: All alerts and generated cases from identity, integrity and risk checks must be analyzed and decided, if necessary only after an extended check, also called "enhanced due diligence" (EDD). A case management system makes all of this transparent, enables the necessary processing quality to be ensured, and enables the complexity-controlled distribution or delegation of leads, cases or partial aspects thereof. Typically, the software solution generates a proposal for the initial risk to be confirmed or rejected based on the previous testing steps. This, in turn, defines that the risk should ideally be subdivided as follows:
  • Initial risk, which is initially identified and confirmed during onboarding.
  • Ongoing risk that continuously arises and changes as a result of collaboration (primarily through risk-relevant master data changes or corresponding events and transactions).
  • Manual risk, which is manually controlled by an appropriately authorized employee.
  • Inherited risk, which exists, for example, due to company affiliation or beneficial owners. In contrast to the aforementioned three, this type of risk is optional in connection with business partner compliance.
• Approval Management: The acceptance of a specific risk position of a specific business partner must be approved by the company's decision-makers in close cooperation with Compliance. In most cases, Compliance acts only as an advisor; in other cases, it should demand a right of decision or veto. This is done as part of the approval management process. In connection with the risk model mentioned above, an identified gross risk resulting from the risk analysis can thus be mitigated by measures related to the business relationship and the associated contract administration - if this is allowed. In such a case, the result is then the net risk on which a decision would have to be made. It goes without saying that all measures must be logged as part of the approval process in order to ensure auditability. The process-related illustration above shows that this does not only apply to approval management, but runs through the entire process.
• Reporting: In addition to audit reports, this includes the regulatory requirements for management reports, which should be supported from within the application on a template basis so as to save time and effort. Reporting for management on the risk situation along the supply chain and governance across the entire business partner process should also be mentioned in this context.

After the core processes have been roughly described, the question arises of the actors who must work on or with such a system, in other words, the question of interfaces and user roles. Here, too, the list is shown schematically.

Interfaces:

• ERP System(s): This primarily refers to the system in which the master data is managed. This can be an ERP system, or it can be a CRM, SCM, MDM, bidding portal, or similar system that manages business partner master data, events, and transactions (e.g., Microsoft, Salesforce, SAP, and others). It is not uncommon to have multiple systems. The type of integration determines the degree of automation and the acceptance of the system in the overall process.
• Credit Agencies/Research Providers: These are public or licensed providers of relevant content on business partners that can/should be used for master data maintenance as well as for risk assessment (e.g., Dow Jones, Dun & Bradstreet, Moody's, but also public lists of the EU, UK, USA, etc.). Here, from a risk perspective, it is necessary to define which providers and data sources should be worked with. For example, there are special providers who specialize in business partners from certain regions, e.g., the former CIS states or the Arabic-speaking world, as well as generalists. Depending on the risk appetite, one provider can be chosen for the simple risk check, and another for the extended risk check or quality assurance
• Internet: For a deeper online research on a specific business partner, an Internet search that can be logged should be provided.
• Whistleblower/Complaint Management: The possibility to lodge a complaint about direct/indirect business partners must be set up and covered, e.g. according to LkSG. An investigation and risk reassessment must then be performed. This can be implemented as an interface to an existing system or by means of a company directive and manual recording of a corresponding note as part of the core process for case management.

With regard to the interfaces, it should be noted that this does not address specific, country- or industry-specific reporting requirements to regulators, which may be another interface requirement.

User roles:

• BP Requestor: This role requests a new business partner/vendor and/or a new business partner relationship.
• BP Owner: This role "owns" and is responsible for a specific business partner and/or business partner relationship.
• Compliance: This role is only intended as an example of Compliance as a user role. This role can be sub-divided as required.
• Approver: This role exemplifies the business decision makers who can review and approve/deny the addition of a specific business partner and/or change the risk potential of an existing business partner.
• Business Partner: The business partner or vendor can be directly involved in the process as part of a self-service.

With regard to the roles, it should be noted that these must always be set up on a company-specific basis and that these, as well as the role designations, may well be different.

This roughly results in the following use case diagram for an IT-supported supply chain compliance system:

Fig. 2: Use case diagram of an IT-based system for supply chain compliance (without event/transaction monitoring).

The outlined IT-supported implementation of a business partner compliance system is generic and, in this form, can support the regulatory compliance requirements for cooperation with business partners in general (sales partners, joint ventures, research initiatives, HR partners, etc.) and vendors in particular. Regulatory specifics have been omitted for clarity, as have industry-specific requirements. As part of this blog series, we will soon also provide insights and examples on risk model, audit strategy and reporting. So it's worth following the #rethinkcompliance blog and staying tuned.