210) may be included within the data by multiple different DBA names (e.g., “Company A, LLC” 211; “Company A LLC” 212; and/or “Company A, Ltd.” 213) even though each refers to the same entity (e.g., Company A 210). When the supply chain analysis engine 116 analyses the supply chain data 102, it is useful to screen the data for a single legal entity together. Thus, it is useful to perform entity resolution and consolidation to identify DBA names and associate them with a single legal entity.

In an effort to address these and other shortcomings, one or more embodiments described herein provide for identifying different DBA names for a single legal entity, grouping the DBA names for that single legal entity together, and assigning a unique identifier to each unique entity inclusive of the DBA names for that entity, while avoiding incorrect identification of a subsidiary as the same entity.

Turning now to FIG. 3, a system 300 is depicted for entity resolution and consolidation using a unique identifier according to one or more embodiments described herein. In the example of FIG. 3, the supply chain analysis engine 116 of FIG. 1 is embodied as a cloud node 302 of a cloud computing system (not shown) but is not so limited. The cloud node 302 can use one or more processing devices and memory resources from a cloud computing system, where the precise location of the processing devices and memory resources need not be known and can be dynamically allocated, used, and released as driven by processing and storage demands.

The supply chain analysis engine 116 receives supply chain data 102 (e.g., the (e.g., supply chain data A 102a, supply chain data B 102b, supply chain data C 102c). The supply chain data 102 can be received from different sources 104 as in FIG. 1. Each of the supply chain data A 102a, supply chain data B 102b, supply chain data C 102c can include data about entities, including DBA names. As described herein, the supply chain data 102 from the different sources 104 can include the same or different types of information, the same or different formats of data, and/or the like, including combinations and/or multiples thereof. For example, the supply chain data A 102a can be in a first format and can include a first type of information (e.g., global trade data); the supply chain data B 102b can be in a second format and can include a second type of information (e.g., cyber data); and the supply chain data C 102c can be in a third format and can include a third type of information (e.g., government spending data). It should be appreciated that the supply chain data 102 is voluminous. As an example, the supply chain data 102 can include billions of data points; consequently, analyzing the supply chain data 102 cannot practically be performed in the human mind.

The supply chain analysis engine 116 stores the supply chain data 102 in source tables 304, which could be tables of a relational database, for example, or other such data structures. The supply chain analysis engine 116 then identifies unique entities and DBA names at block 306. To do this, the supply chain analysis engine 116 analyzes the supply chain data 102 to identify entities with the same or similar names. The supply chain analysis engine 116 uses the supply chain data 102 to identify different DBA names and groups them together. For example, the supply chain analysis engine 116 can analyze invoice data and understand that a single legal entity (e.g., Company A 210) issues invoices using DBA names “Company A, LLC” 211; “Company A LLC” 212; and/or “Company A, Ltd.” 213. The supply chain analysis engine 116 can compare information about the DBA names (e.g., address information, corporate registration information, etc.) to determine that the DBA names are, in fact, DBA names that relate to the Company A 210 and are not unique entities.

At block 308, the supply chain analysis engine 116 assigns a unique identifier to each unique entity inclusive of the DBA names for that entity from block 306. In one example, a proprietary hash can be created as the unique identifier using information about the entity and/or DBA names. As an example, a standardize format uniform resource locator (URL) associated with the unique entity can be hashed to generate the unique identifier. Using a standardized format URL (e.g., “companyA.com”) is one of the many unique identifiers that can be hashed in order to create the unique identifier, for example. Other items that can be used as unique identifiers include, for example, data universal numbering system (DUNS) numbers, unique entity identifiers (UEIs), commercial and government entity (CAGE) codes, universal product codes (UPCs), service set identifiers, internet protocol addresses, and/or other unique identifiers known in the art. According to one or more embodiments described herein, an algorithmic selection can be used to determine which DBA to treat a primary DBA (e.g., based on number of occurrences, most recent occurrence, etc.). Where more than one unique identifier is available, embodiments can use priority-based selection to select the unique identifier with a highest degree of confidence as being unique for deriving a hashed unique identifier. This approach can allow many different potential unique identifiers to be used collectively with a unique and compact format of identification. For instance, where the unique identifier is text-based, the hashed format can effectively compress the identifier to reduce storage requirements while remaining unique. In some aspects, where identifier tuples exist, a unique identifier can be derived based on the combination of identifiers, which can be a weighted combination.

At block 310, the unique identifier can be added to the supply chain data 102 to join the unique identifier to the source tables 304. The join can be performed using any suitable database join technique, such as an inner join, an outer join, a cross-join, and/or the like, including combinations and/or multiples thereof.

The unique identifier can be used for screening, for example, by sending a request 320 to a screening service (not shown). The screening service can return a response 322 as a percentage matching a watchlist score for the entity based on the unique identifier. The supply chain analysis engine 116 can store the response 322 as raw results 312. The supply chain analysis engine 116 can count a number of watch list occurrences (e.g., “hits”) that occur for the unique identifier at block 314. The percentage can be compared to a threshold (e.g., 0.50), for example, for identifying issues associated with the entity having the unique identifier at block 316. For example, no issues may be considered to exist if the percentage is less than the threshold. However, when the threshold is satisfied (e.g., met or exceeded) the supply chain analysis engine 116 can generate results 118. The results 118 may identify the unique identifier of the entity for which the watchlist occurrences satisfied the threshold as well as information about the entity, information about why the alert occurred, and/or any other suitable information. According to one or more embodiments described herein, the results 118 can include a recommendation for an alternative supplier/vendor. In some aspects, data structures can be defined down to an entity, industry, and location level with passive inheritance used to link the unique identifier to the data stream and roll up associations to primary records with normalized identifiers applied across data sets. Pre-mapping can allow risks to be passed through continuous passive inheritance to stream data content to an identifier structure rather than performing a delta/difference analysis to determine which records have changed and need an update. This approach can avoid manual intervention for conflicting or ambiguous records by performing frequent full rebuilds to ensure that newly derived data is available when a user logs in. By having records for a user prebuilt/rebuilt based on scheduled actions, search times can be reduced and repetitive/redundant searches can be avoided.

FIG. 4 is a flow diagram of a method 400 for entity resolution and consolidation using a unique identifier according to one or more embodiments described herein. The method 400 can be implemented by any suitable device or system, such as the processing system 100 of FIG. 1, the system 300 of FIG. 3, and/or the processing system 700 of FIG. 7 as a computer-implemented method. The method 400 is now described with reference to the system 300 of FIG. 3 but is not so limited.

At block 402, the supply chain analysis engine 116 of the system 300 receives the supply chain data 102. The supply chain data 102 can be received from a single source or a plurality of sources (e.g., the sources 104 of FIG. 1). According to one or more embodiments described herein, the supply chain data 102 can include global trade data, cyber data, and/or government spending data.

At block 404, the supply chain analysis engine 116 of the system 300 analyzes the supply chain data to identify a unique entity and a DBA name associated with the unique entity. According to one or more embodiments described herein, the DBA name is one of a plurality of DBA names associated with the unique entity. That is, the unique entity can have one or multiple DBA names associated therewith.

At block 406, the supply chain analysis engine 116 of the system 300 generates the unique identifier for the unique entity. For example, at block 308 of the system 300, the supply chain analysis engine 116 generates the unique identifier. According to one or more embodiments described herein, the unique identifier is a hash. According to one or more embodiments described herein, the hash is based at least in part on information about the unique entity. According to one or more embodiments described herein, the hash is based at least in part on a uniform resource locator associated with the unique entity.

At block 408, the supply chain analysis engine 116 of the system 300 associates the unique identifier with the unique entity and the DBA name associated with the unique entity. For example, at block 308 of the system 300, the supply chain analysis engine 116 assigns the unique identifier to the unique entity.

At block 410, the supply chain analysis engine 116 of the system 300 updates the supply chain data (e.g., metadata associated with supply chain data 102) to include the unique identifier for the unique entity and the DBA name associated with the unique entity. For example, at block 310 of the system 300, the supply chain analysis engine 116 joins the unique identifier to the source tables 304 storing the supply chain data 102.

Additional processes also may be included. According to one or more embodiments described herein, the method 400 includes performing a supply chain analysis using the supply chain data 102 updated with the unique identifier. The supply chain analysis identifies potential risks (e.g., cyber threats, financial threats, fraud, and/or the like, including combinations and/or multiples thereof) associated with the unique entity. It should be understood that the process depicted in FIG. 4 represents an illustration, and that other processes may be added or existing processes may be removed, modified, or rearranged without departing from the scope of the present disclosure.

The unique identifier created as described herein can be used when analyzing supply chain data. For example, the processing system 100 of FIG. 1 can use the unique identifier to generate the results 118 based on the supply chain data 102. For example, the supply chain analysis engine 116 can use the unique identifier to generate enriched commerce data from global trade data, enriched cyber data from cyber data, and enriched contracts data from government spending data.

The commerce data identifies shipping information such as ports, shipping containers, identification of transport from one port to another, descriptions of contents of containers, harmonized system (HS) code data, company information (e.g., shipper and consignee), and/or the like, including combinations and/or multiples thereof. The cyber data describes software usage, such as which particular software applications are being used at which entities.

For the commerce and cyber data, it may not be evident how parties farther up or down the supply chain may be impacted or may be impacting the shipper and/or consignee. For example, with reference to FIG. 2A, a supplier 230 to Company A 210 may use a software application for managing a portion of its business. The software application may be known to be defective (e.g., a new version is release that includes undesirable effects, the software has malicious code, and/or the like, including combinations and/or multiples thereof). As a result, the use of the software application by the supplier 230 may cause disruptions to the operation of the supplier 230, which may in turn cause disruptions to the operation of Company A 210. It should be appreciated that the supplier 230 may be a direct supplier to Company A 210 or may be farther up the supply chain relative to Company A 210. Thus, it may not be readily apparent that a disruption to the supplier 230 may negatively impact Company A 210.

According to one or more embodiments described herein, a multitier approach is provided that identifies the parties farther up the supply chain (e.g., farther up from a shipper) and farther down the supply chain (e.g., farther down from a consignee). For example, in the case of cyber data, one or more embodiments can crawl and scrape publicly available information (e.g., online entity information, job postings, resumes, etc.) associated with a party (e.g., a vendor, supplier, etc.). Using this information, it can be determined which particular software applications are being used at which entities up and down the supply chain. Then, when a new software vulnerability arises, for example, the parties in the supply chain that use that software can be identified. This can enable identifying potential impacts to the shipper and/or consignee.

FIG. 5 is a flow diagram of a method 500 for analyzing supply chain data using a unique identifier according to one or more embodiments described herein. The method 500 can be implemented by any suitable device or system, such as the processing system 100 of FIG. 1, the system 300 of FIG. 3, and/or the processing system 700 of FIG. 7 as a computer-implemented method. The method 500 is now described with reference to the system 300 of FIG. 3 but is not so limited.

Sources 104 provide supply chain data 102 as supply chain data A 102a (e.g., global trade data), supply chain data B 102b (e.g., cyber data), supply chain data C 102c (e.g., government spending data), and other supply chain data 102n. The supply chain data 102 is then passed into a first phase 510 of the method 500. The method 500 includes multiple extract, transform, load (ETL) phases 510, 520, 530, 540. The ETL phases 510, 520, 530, 540 provide for extracting information from the supply chain data 102, transforming the data, and loading the data for subsequent phases.

The supply chain data 102 are fed into ETL phase 510. Block 511 represents company (e.g., entity) names that are missing a source system identifier (SSID). Block 512 represents company (e.g., entity) names that include an SSID. The SSID is an identifier is used to specify unique records. Block 513 represents the supply chain data A 102a being enriched (e.g., added HS code and shipping information), formatted, and cleansed. Similarly, block 514 represents the supply chain data B 102b being enriched, formatted, and cleansed. Block 515 represents the supply chain data C 102c being formatted and cleansed. As described with reference to FIG. 6, enriching the data can include crawling and scraping publicly available information to supplement the supply chain data 102.

With continued reference to FIG. 5, the data from the phase 510 is then passed to phases 520 and 530 as shown. Particularly, the data from block 511 and 512 is passed to block 521 of phase 520. Block 521 represents the unique identifiers (IDs) (e.g., company_ID, URL, data universal numbering system (DUNS) number, company, country, and/or the like, including combinations and/or multiples thereof).

At phase 530, data is received from phase 510 and 520 as shown. Particularly, the company IDs from block 521 are passed to block 531, 532, and 533, which respectively represent commerce data, cyber data, and contracts data. Block 531 also receives data from block 513, block 532 also receives data from block 514, and block 533 also receives data from block 515. Block 531 combines the enriched supply chain data A from block 513 with the unique identifier from block 521. Block 532 combines the enriched supply chain data B from block 514 with the unique identifier from block 521. Block 533 combines the formatted and cleansed data from block 515 with the unique identifier from block 521.

Blocks 531, 532, and 533 each feed into block 541 of phase 540 and into blocks 534 and 535 of phase 530. Block 541 of phase 540 combines company names and addresses with the respective unique identifier for a unique entity. This can be done, for example, based on the unique identifier, an identifier for the supply chain data A from block 513, the URL, DUNS number, company name, full address, and/or the like, including combinations and/or multiples thereof. Block 534 of phase 530 represents a dataflow for screening against compliance watchlists using the unique identifier. That is, the unique identifier can be fed into compliance watchlists to determine whether the entity associated with the unique identifier (e.g., the legal entity and any associated DBA names) are on any compliance watchlists. Block 535 of phase 530 represents dashboard and reporting environments where watchlist hits (e.g., resulting from block 534) are generated. The dashboard and reporting environments can be implemented as user interfaces on any suitable device (e.g., smartphone, laptop, and/or the like, including combinations and/or multiples thereof).

Additional processes also may be included, and it should be understood that the process depicted in FIG. 5 represents an illustration, and that other processes may be added or existing processes may be removed, modified, or rearranged without departing from the scope of the present disclosure.

FIG. 6 is a flow diagram of a method 600 for enriching supply chain data according to one or more embodiments described herein. The method 600 can be implemented by any suitable device or system, such as the processing system 100 of FIG. 1, the system 300 of FIG. 3, and/or the processing system 700 of FIG. 7 as a computer-implemented method. The method 600 is now described with reference to the system 300 of FIG. 3 but is not so limited.

At block 602, the supply chain analysis engine 116 of the system 300 receives the supply chain data 102. The supply chain data can be received from a single source or a plurality of sources (e.g., the sources 104 of FIG. 1). According to one or more embodiments described herein, the supply chain data can include global trade data, cyber data, and/or government spending data.

At block 604, the supply chain analysis engine 116 of the system 300 identifies a party (e.g., the supplier 230) associated, via a supply chain, with an entity (e.g., Company A 210) based at least in part on the supply chain data. According to one or more embodiments described herein, identifying the party can be performed using a unique identifier for the entity, as described herein (see, e.g., FIG. 4). According to one or more embodiments described herein, the unique identifier is a hash. According to one or more embodiments described herein, the hash is based at least in part on information about the unique entity. According to one or more embodiments described herein, the hash is based at least in part on a uniform resource locator associated with the unique entity.

At block 606, the supply chain analysis engine 116 of the system 300 collects additional data about the party. According to one or more embodiments described herein, the additional data can be commerce data relating to the party. As an example, the commerce data identifies one or more of a port, a shipping container, a transport from the port to another port, contents of the container, harmonized system code data, and/or company information about a shipper and a consignee. According to one or more embodiments described herein, the additional data can be cyber data relating to the party. For example, the cyber data identifies software usage of the party (e.g., what software applications the supplier 230 is using). According to one or more embodiments described herein, collecting the additional data about the party includes crawling and scraping publicly available information (e.g., online entity information, job postings, resumes, etc.) associated with the party.