AU2004320849A1 - Systems and subsystems for risk assessment and management - Google Patents

Description

WO 2005/124622 PCT/US2004/029364 SYSTEM AND METHOD FOR RISK ASSESSMENT AND MANAGEMENT IN A VARIETY OF SYSTEMS AND SUBSYSTEMS Cross-Reference To Related Applications This application is related to U.S. Patent Application Serial No. 10/895,014 filed July 20, 2004 entitled "SYSTEM AND METHOD FOR SUPPLY CHAIN COLLABORATIVE RISK MANAGEMENT", and Patent Cooperation Treaty Application No. PCT/US/18218 filed June 8, 2004 entitled "A SYSTEM AND METHOD FOR RISK DETECTION, REPORTING AND INFRASTRUCTURE", the entire disclosures of which are each respectively hereby incorporated by reference herein as if being set forth in their respective entireties. Background of the Invention Field of the Invention The invention relates to the field of risk management, and more particularly, to collaborative risk analysis of systems and subcomponents, including business processes of industrial networks, as well as associated processes of documents and messages related to a risk slate. Description of the Background Risk b ased d ecision-making i s a n ecessary p art o f t he m anagement o f virtually any sort of business. For example, banking and investment institutions assess risks, and make risk d eterminations on investments, loans, and other transactions based on those assessed risks. Financial institutions, for example, may look at risks that include foreign exchange risk, reputation risk, credit risk, and operational risk in making determinations about, among other things, types, costs and approaches to entering into counterparty transactions. Insurance companies may make similar determinations to evaluate risk versus reward, and issue an insurance policy based on the probability of claims and the magnitude of those likely claims. In such instances, available and appropriate historical data may be used to support decision making for current and future actions.

WO 2005/124622 PCT/US2004/029364 Further, the processes of industrial networks, such as, the trading of goods, is also often subject to risk. For example, shipping goods internationally may be subject to various risks, including, inter alia, theft, smuggling of people (including terrorists) or contraband, cargo tampering, or terrorist delivery of nuclear, radiological, biological, chemical or conventional explosives, materials or weapons. Securing the global supply chain may be difficult because legal and physical control of goods in transit typically changes between various entities, such as manufacturers, sellers, brokers, financiers, truckers, ocean carriers, certain integrated logistics providers, customs house brokers and buyers, for example. Arranging global logistics has thus become increasingly complex, as various entities may be involved and may contribute relevant risk information, including freight forwarders, third party logistic providers and lead logistics providers, for example. The facilities, equipment, processes and systems that make up the global supply chain may be monitored for risk factors to permit decision makers to determine whether a particular container or item represents a level of risk along a risk continuum measured in severity from, for example, acceptable to unacceptable. By correctly analyzing and ranking risk, companies and governments may be enabled to concentrate response resources on higher risk or i dentified-as-potentially-dangerous o r d angerous s hipments. The ability to share certain information up stream and down stream in the supply chain, and across supply chains, to thereby allow for supply chain participants to collaboratively manage risk, may be a key to increasing supply chain security overall. The need to share information to decrease security risk may be acute. For example, the global shipping industry, like the global airline industry, attempts to serve its customers by having regular schedules and sufficiently frequent service to address customer needs. However, few, if any, ocean carriers operate sufficient equipment to provide necessary service coverage. Thus, Ocean Carriers often make cargo carrying arrangements collaboratively to extend their respective coverage. In practice, almost every Ocean Carrier books containers that are then carried on a competitor's ships. Technologies have been developed to assess risks, share information and support determinations for actions based on the assessed risks. However, processes and architecture for risk management in business processes have historically been difficult to deploy across one or a multitude of local and external business and technological domains. Further, in existing systems, once risk based decisions are made, various 2 WO 2005/124622 PCT/US2004/029364 actions may be difficult to perform, including the denial of a transaction to be performed, or initiation of new transactions or transitions, such as to make and/or sell automatically to rebalance accounts or qualify for or obtain insurance for example, and/or notification warnings to appropriate personnel. Data security controls use risk assessment with regard to data systems (e.g., networks and computers). Based on a specified policy that sets forth what is acceptable and unacceptable, and which may include attention to "Signatures", patterns of appropriate or inappropriate actions (actions on the host/network system) may be allowed or denied. Historical information may be kept to determine, in part, what may be acceptable based on past actions. Thus, actions may be allowed or denied in the present and/or future based on what has been allowed in the past. One such implementation for data security controls is known in the art as a firewall. Intrusion detection systems (IDS) may be used in computer systems and networks. IDSs may be used to detect and identify unauthorized use of a computer(s). Generally, an IDS looks for specific patterns, or Signatures, via logs, network traffic, file modification and other sources available, to detect malicious activity. These signatures may be identified using, for example, finite state machines, simple pattern matching, or specialized algorithms. Many IDSs may be prone to both false positive and false negative alerts. False positives occur when the IDS identifies a problem such as unauthorized activity when such a problem has not occurred. False negatives occur when an IDS does not detect a problem when a problem has occurred. In light of the reliance on historical data and the possibility of false positives and false negatives, in order to fully protect a system, mere Signatures of negative patterns may be desirable but not sufficient. A negative Signature approach addresses the identification of that which is not allowed. The complementary approach, namely the positive Signature approach, defines specifically that which is allowed, or at least acceptable within a tolerable deviation. Rules, also termed herein as Policies, represent those actions that may be specifically allowed and/or those actions that may be specifically denied. Rules specify the parameters within which transactions operate. A dynamic rule is one in which various responses may change over time such as in response to particular inputs, such as response changes based on various considerations. 3 WO 2005/124622 PCT/US2004/029364 Ideally, rules used for IDS testing would be dynamic rules. However, because, rules may be often "hard coded" as part of the binary code of a security system, rules may not be truly dynamic. The lack of dynamic rules may cause difficulty in a variety of situations, including, for example, when the security software is updated (e.g., the executable code becomes longer and slower, and machines must be turned off to upgrade). Further, business processes may be typically far more complex than the rules associated with intrusion against a computer system operating those business processes. For example, flows of information may come from multiple entry points, and may not arrive at centralized points. In order to hide the lack of dynamic rules, and to account for the ever-increasing complexity of business processes, network based firewalls may change an IP address via Network Address Translation, more commonly known as NAT, or via Port Address Translation, more commonly known as PAT, to hide a particular internal network configuration. However, in such a "fix", the context of the messaging stays the same although the content seen has been modified. Such fixes may be inefficient to hide, or remedy, changes or terminations of business processes for specific transaction types, and may be likewise inefficient to vary the allowability or disallowability of specific transactions or states over time. Further, such fixes do not allow for various monitoring or control techniques to be added dynamically in a simple manner, as various risks throughout an enterprise distributed process may be identified and addressed. Such computer systems, and physical networks, that implement rules to avoid risks may use rules to implement information sharing requirements, and subsequently may cause tensions among entities in a supply chain. For example, there is a class of businesses known as non-vessel operating common carriers (NVOCCs) which may take possession of cargo directly from an end user and issue a bill of lading to the customer in exchange for the cargo. By definition, the NVOCC does not operate a vessel, and therefore, consigns the cargo to a carrier in exchange for a subsequent bill of lading. In this instance, certain customer, shipment and container data may reside with the NVOCC. Information sharing also arises in the context of load consolidation. Many people or organizations attempt to ship goods that do not completely fill a container load. Consolidators may become involved and issue a bill of lading or other ownership document to a customer, and may attempt to consolidate a number of loads into a single 4 WO 2005/124622 PCT/US2004/029364 container, thereby filling the shipping compartment. In such a configuration, the consolidator may hold the customer and cargo data. Carriers may carry on their ships a significant percentage of cargo for other carriers, NVOCCs and consolidators. This cargo may be carried on a common carriage basis, that is, the container must be accepted for carriage if the freight is paid and there is no good basis upon which to refuse carriage. The risk profile of a particular container or item may be affected by a number of factors. The data associated with the factors may be held by a number of different entities; yet, all of it may be important to determining whether a container should be permitted to be laden upon a container ship, delivered to a port, or released from a government's custody. Moreover, determining aggregate risk through analysis of the risk profile of single container may not be sufficient. Relationships amongst multiple containers, shipments and other factors may be necessary to determine the overall risk of an undesirable event. Risk related data may be generated or held by a number of different entities. Further, companies participating within the global supply chain may be requested to address security concerns, such as in the event of a terrorist threat potential. However, there is, currently, no global standard to be met in this situation, and therefore it is difficult for companies to know what to do or how to respond. Shipped cargo often moves through certain choke points, such as consolidation centers, container yards, ocean terminals and container ships, where cargo from one supply chain may be intermingled with c argo from o ther c hains. S ecure s upply c hains in ay be exposed to certain risks resulting from proximity to cargo being moved in a less secure fashion. Spending to increase the security of one chain or the chain of one company may not be effective, as the determining factor is the weakest link. Therefore, all companies must be subject to similar standards. Without mandatory or optional standards and guidelines, companies my be left to individually determine the sufficiency of security, leaving such companies open to legal liability for not doing enough in the event of an incident, while disincentivizing doing more because spending more on security than one's competitors may put one at a business disadvantage. It may be desirable that all parties be working to a common or standardized baseline of security practices. The carrying entity may be required to carry cargo booked by a separate booking entity and tracked by a separate tracking entity, and may prefer to understand that the security and risk related procedures 5 WO 2005/124622 PCT/US2004/029364 followed by these other entities are sufficient to meet the security and risk requirements of the carrying entity. The effort to implement collaborative risk management in a supply chain context may be complicated by the fact that certain of the participants in a single supply chain may be competitive with one another. For example, it is embedded in the ocean carriage business model that carriers, NVOCCs, consolidators and others book container passage with carriers either on a spot basis or pursuant to forward contracts. A booking entity may desire to withhold information from the carrying entity, particularly customer data, for fear of circumvention, such as the carrying entity attempting to circumvent the booking entity and communicate directly to the customer. The insurance world may compare premiums and related revenues against payouts due to occurrences and related expenses in determining whether to provide a line of insurance cover. This determination may be difficult in terms of terrorism related risks. Unlike natural occurrences, terrorist acts cannot be predicted in terms of number of events or magnitude of associated losses. In addition, particular risks may not be covered, such as nuclear or certain radiological risks, for example. T hese p articular risks tend to b e considered catastrophic risks for which insurance coverage cannot be economically provided. As may be known to those possessing an ordinary skill in the pertinent arts, financing agencies, such as banks, for example, may be sensitive to risk parameters within their customer base, and financing costs may vary based on compliance or level of compliance. Both buyers and sellers may wish to monitor for risk factors that may affect performance either in delivering goods or in making payments. Another consideration is that various entities may wish to limit the risks taken as compared to other entities within the system. A portion of the risk that may be addressed in making decisions within any system may be the knowledge of whether data originated with an authenticated and authorized source and whether data from an authenticated and authorized source is received uncorrupted or without unauthorized changes. Risk information relevant to a particular document, shipment or supply chain element may be held by various parties that have costs associated with the collection of that information. This information may be valuable and other entities may wish to purchase it on some commercial basis. Formalized mechanisms for structuring, pricing 6 WO 2005/124622 PCT/US2004/029364 and exchanging this information may not be available. Therefore a need exists to permit incorporation of pricing models for information into the data exchange protocols. Further, a need exists to provide for security and risk information transfer between and amongst supply chain participants and national or international agencies for decision support, and/or for liability bearing representations regarding compliance to security or risk standards to be made from one supply chain participant to another, either directly or through intermediaries. Thus, the need also exists for a system, method, and device capable of efficiently monitoring risk, and that allows for flexibility in modifying, communicating, or updating risk policy, while also providing sufficient security or risk related information or representations to carrying entities to c omply with any external o r internal c ompliance requirements. Summary of the Invention The present invention includes a system and method for risk management associated with at least one business process. The system includes a first node which forms at least a portion of a plurality of communicatively connected nodes for collecting at least one risk related data value that is associated with at least one document; a second node of the plurality of communicatively connected nodes that is communicatively connected to the first node that receives the at least one risk related data value and, in accordance with the at least one risk related value, evaluates the at least one document associated with the at least one risk related value against at least one of a plurality of risk categories. The second node also implements the at least one risk category pursuant to at least one risk policy approved by a central one of the plurality of communicatively connected nodes for the at least one business process, and further determines whether a risk o f the at least o ne d ocument e xists p ursuant t o a r ating score for the at least one document according to the at least one risk category. The method of managing risk includes the steps of collecting at least one risk related data value associated with at least one document; evaluating the at least one document associated with the at least one risk related data value against at least one of a plurality of risk categories; implementing the at least one risk category pursuant to at least one risk policy approved by a central node of a plurality of communicatively connected nodes for the at least one business process; and determining whether a risk of the at least 7 WO 2005/124622 PCT/US2004/029364 one document exists pursuant to a rating score for said at least one document according to the at least one risk category. Thus, the present invention provides a system, method, and device capable of efficiently monitoring risk, and that allows for flexibility in modifying, communicating, or updating risk policy, while also providing sufficient security or risk related information or representations to carrying entities to comply with any external or internal compliance requirements. Brief Description of the Figures Understanding of the present invention will be facilitated by consideration of the following detailed description of the preferred embodiments of the present invention taken in conjunction with the accompanying drawings, in which like numerals refer to like parts: FIG 1 is a diagram depicting mapping between Document, Risk Categories and Policy; FIG 2 is a diagram depicting multiple risk policies against multiple Document Instances; FIG 3 is a diagram depicting relationships between Documents, policies and Qualifications; FIG 4 is a diagram depicting the obtaining by a Document Instance of values from a database(s) to incorporate into fields (values); FIG 5 is a diagram depicting components of an RDS; FIG 6 is a diagram depicting secure transmission of Templates; FIG 7 is a diagram depicting the performance of policies from different organizations; FIG 8 is a diagram depicting secure transmission of Instances or Templates from an RDS; FIG 9 is a diagram depicting user access as related to a Trust Manager; 8 WO 2005/124622 PCT/US2004/029364 FIG 10 illustrates a diagrammatic representation of the roles, flows and organization of the present invention; FIG 11 illustrates a diagrammatic representation of the standards creation and implementation of the system of Figure 10; FIG 12 illustrates a privacy, compliance, aggregation and payment representation according to an aspect of the present invention of the system of Figure 10; FIG 13 illustrates a risk transfer, information aggregation and trust infrastructure of the system of Figure 10 according to an aspect of the present invention; FIG 14 illustrates a specific embodiment of the system of Figure 10; and, FIG 15 is a diagram depicting the combination of multiple Documents into one using the method of FIG 4. Detailed Description of the Preferred Embodiments It is t o b e understood that the figures and d escriptions o f t he p resent invention have been simplified to illustrate elements that are relevant for a clear understanding of the present invention, while eliminating, for the purpose of clarity, many other elements found in typical risk management systems and methods of using the same. Those of ordinary skill in the art may recognize that other elements and/or steps are desirable and/or required in implementing the present invention. However, because such elements and steps are well known in the art, and because they do not facilitate a better understanding o f the present invention, a discussion of such elements and steps is not provided herein. The disclosure herein is directed to all such variations and modifications to such elements and methods known to those skilled in the art. Risk related data may be generated or held by a number of different entities. For example, in an industrial networks environment, information about different parties involved in a transaction, such as the identity of and information about an importer, consignee, source manufacturer, or seller, may initially or eventually be in the possession 9 WO 2005/124622 PCT/US2004/029364 of an entity that books passage of a particular container. Information about the facilities where the container may be stuffed or stored in transit may be initially or eventually held by any number of parties, or by third party auditors or assessors working on their behalf. Information about containers en route may be held by an in-land (or ocean) carrier, such as a truck, rail, or barge that is hauling the container, while information about the loading or unloading terminal, and a carrier, such as a vessel, itself and its route may be held by a carrying entity or a tracking entity. It goes without saying that a sufficient amount of this information should be available to the carrying entity, and in some cases to governmental authorities, so that an appropriate risk based decision may be made whether to carry a particular container or cargo item. Moreover, under current regulatory schema, a carrier, or NVOCCs, may be, pursuant to the 24 Hour Advance Manifest Rule, responsible for submitting appropriate security related information to the United States Customs authorities for containers going into a United States controlled port, whether off-loaded or not. Other countries have, or are anticipated to have similar requirements. For example, shipped cargo often moves through certain choke points or bottlenecks, such as consolidation centers, container yards, ocean terminals and container ships, where cargo from one s upply c hain m ay b e intermingled w ith c argo from o ther chains. Secure supply chains may be exposed to a number of risks resulting from proximity to cargo being moved in a less secure fashion. Spending to increase the security of one chain or the chain of one company may not be effective. Therefore, all companies incident on a supply chain should be subject to a similar set of standards, rules, or policies. In this regard, it may be desirable that all parties be working to a common baseline of security practices. Further, the carrying entity may be required to carry cargo booked by a separate booking entity and tracked by a separate tracking entity, and may prefer to understand that the security and risk related procedures followed by these other entities are sufficient to meet the security and risk requirements of the carrying entity. While various mechanisms of accomplishing this understanding may be contemplated, according to an aspect of the present invention, security and risk standards may be followed or implemented according to a baseline or normalization. In an example, insurers may compare premiums and related revenues against payouts due to occurrences and related expenses in determining whether to provide a line of insurance coverage. This determination may be difficult in terms of terrorism related 10 WO 2005/124622 PCT/US2004/029364 risks, for example. Unlike natural occurrences, terrorist acts cannot be predicted in terms of number of events or magnitude of associated losses. However, there is a strong policy initiative for insurance companies to offer coverage for terrorist acts, as evidenced by the United States' Terrorism Risk Insurance Act of 2002 (TRIA). The TRIA provides a mechanism requiring insurance companies to offer terrorism coverage, and also provides approximately one hundred billion dollars ($100,000,000,000) of governmentally provided indemnity backstop. In addition, particular risks may not be covered by insurance, such as nuclear or certain radiological risks, for example. These particular risks tend to be considered catastrophic risks for which insurance coverage cannot be economically provided. However, it is in the interests of government, business and the public that commercial risk transfer products take on at least part of this risk, even if some of the risk must be eventually deflected to the public sector. Underwriting standards and monitoring for compliance may be a key to controlling these risks. As may be known to those possessing an ordinary skill in the pertinent arts, financing agencies, such as banks, for example, may be sensitive to risk parameters within their customer base, and financing costs may vary based on compliance or level of compliance. Banks may wish to monitor certain information, or receive representations regarding certain information or practices, in order to set, maintain or adjust financing rates. Various entities within the system may wish to limit the risks taken as compared to other entities within the system. For example, one entity, which may be a node within the system, may wish to limit the type of information it accepts from another node, or may wish to limit the dollar value of transactions that it is a party to with respect to another node. These limits may be set on a system wide basis, or on a bilateral basis between nodes. A portion of the risk in a given system may lie in knowing whether data originated with an authenticated and authorized source, and whether data from an authenticated and authorized source is received uncorrupted or at least without unauthorized changes. Various techniques exist within infrastructures to address source authenticity and data integrity. Such techniques include, but are not limited to, symmetric and public key cryptography, for example. Public key cryptography may include both certificate based, such as VeriSign certificates, and certificate-less based, such as account authority based 11 WO 2005/124622 PCT/US2004/029364 digital signatures models, including the known Account Authority Digital Signature Model, approaches. Other methods are well known to practitioners of the art. In a first aspect of the present invention, a system, method, and device is provided that efficiently monitors risk, and that allows for flexibility in modifying or updating at least one risk policy. The present invention monitors risks associated with at least one business process, including: evaluating at least one of a plurality of document instances, wherein each of the document instances includes, in association therewith, a plurality of document values, against a plurality of risk categories; implementing the plurality of risk categories pursuant to at least one acceptable risk p olicy approved for the at l east one business process; and qualifying at least one of the at least one of the plurality of documents pursuant to an approval rating of the at least one document in at least one risk category. Referring now to Figure 1, there is shown a flow diagram illustrating the evaluation of a Document 101, which may include any number of values 104, against a risk Policy 107. Document 101 (hereinafter "Document" or "document") may be provided to the illustrated exemplary system in a variety of ways, such as, for example, via web access, web service, a gateway, physical documentation converted to electronic form, such as by optical character recognition (OCR) or scanning, one or more physical items capable of having one or more characteristics correspondent to one or more values attached thereto or associated therewith, or by any similar methodologies known to those skilled in the art. If the Document is a physical item, such as a paper, equipment, or other cargo, for example, the Document may have attached thereto or associated therewith a signifier, such as a barcode, radio frequency tag, or the like, signifying the characteristics associated with the physical Document. For example, the sensing of a signifier may cause an electronic system associated with the sensor to access the values associated with the physical D ocument. T he p resent invention i s in n o w ay limited b y the m anner in which a Document or its conversion to an electronic form is provided. Document 101, as used herein, may be or represent, include, or be otherwise associated with values that may be important or otherwise relevant to a business system or process, and in particular to security in a business system or process, such as shipping cargo, insurance, or the like. Values may be, for example, fields available in a record, as is known in the art; or another sort of data or information relating to the business system or process. Document 101 may also be multiple Documents, or may be a subset or 12 WO 2005/124622 PCT/US2004/029364 superset o f o ne o r more Documents that may initially have paper based definitions or structure, or that may initially have physical characteristics, or that may be of established or structured data sources. Such data sources or paper based or physical definition may contain or have associated therewith values, including values obtained from other sources outside the Document or Documents. Reference to Document 101 may include, without limitation, reference to any one field or to all fields of values within or associated with the Document. Documents may be defined into a Risk Detection System ("RDS") and its associated infrastructure. For example, a scripting language, or a technique implementing a GUI (Graphic User Interface), or other representations, may be used. According to an aspect of the present invention, an e xtensible language, such as XML [ XML], m ay b e used. The XML used may be in accordance with the "Survey Sample: Web Form Design in ASP.NET" by Allen Wagner. Further, any of a variety of computing aspects, languages, or scripts, including XML, may be incorporated into the present invention. For exemplary purposes, the XML code may include: XML-A <Document Title="BuildingSecurity" SourceType="UserWeblnput" Source="www.xxx.com/survey" > <Destination="MasterDB.BldSecurity"> <Question ID="O" visible="yes" Text="Building Number?" Type="Numeric"> <Answer Tag="BuildingNumber" PrimaryKey="BLD"> </Question> <Question ID="1" visible="yes" Text="What country is building in" Type="Character"> <Answer Tag="CountryValue"> </Question> <Question ID="2" visible="no" Type="real"> <Answer Compute=CountryRiskTable(CountryValue).riskvalue * 4> </Question> <Question ID="3" visible="yes" Text="Are Fences higher than 10 feet?" Type="integer"> <Answer ID="1" Text="Yes"> <Answer ID="2" Text="No"> </Question > 13 WO 2005/124622 PCT/US2004/029364 <Question ID="4", visible="yes" Text="Do fences have barbed wire?" Type="multiple choice> <Answer ID=="1" Text="Yes"> <Answer ID="2" Text="No"> </Question > </Document> According to this aspect of the present invention, Document 101, such as a survey, may be specified. Such a Document specification may create a data definition, although other methodologies to incorporate pre-existing database definitions may be apparent to those skilled in the art. The Source Type may be a web-based input that stores information in an appropriate record under a database, such as under MasterDB.BldSecurity with a primary key of BLD, for example. For purposes of this example, the web site that may be placed is www.xxxx.com/survey. Questions may be numbered using an ID, and may be displayed based on whether the "Visible" flag is set to "Yes", as in the present example. The question to be displayed is provided in "Text" and the type of response is in "Type", as in this example. Any number of questions may be used, and any sort of ID as is known in the pertinent art may be used. Types may include, without limitation, "character," "numeric," "freeform,' "multiple choice", B oolean, o r the like, for example. 0 ther t ypes m ay b e apparent t o those skilled in the art, and may be validated against proper, or improper, input types. "Answer" may have multiple purposes in the above example, and typically may represent a submitter's input. A submitter may be any source, such as a person, a process, or an automated, manual, electronic or mechanical input, by way of non-limiting example only. In the above example, "Tag" may be used as a variable name for questions. In the above example, CountryValue (defined in ID=l) in the ID=2 compute field may view the riskvalue in the CountryRiskTable as indexed by CountryValue. The answer to the question in this example, which is not visible during input in this example, may be the risk value for the country multiplied by four (4). The above example illustrates web-based input. It may be apparent to those possessing an ordinary skill in the pertinent arts that other forms of input may be provided for. For example, questions might not be displayed, but rather may take the form of electronic inquiries, such as inquiries that access information, as "answers" or input, from 14 WO 2005/124622 PCT/US2004/029364 a digital format, such as from a database. Input responsive to a question may, for example, be any transmitted electron packet representing information in a data store, such as a database, directory or flat file. In such cases, the data description may describe the manner of obtaining the values to be input. For example, the data description may state that the value is a specific field within a database table, or the first X bits, starting from bit Y, in a data value. In cases where "visible = 'No"', inputs responsive to questions may also be computed values not taken from human input. Figure 4 represents an exemplary use of "Tag" and "compute." Again, a Document 101 may include any number or any series of values. For simplicity, Values 1 through 4 (above line 402) may be, in this example, values visible to a user, and the remaining values below the line may not be visible to the user. Value n 403 may be a copy of Value 1 in this embodiment, as illustrated. Value 5 405 may be obtained from a local store, such a s a d atabase 406, for example. V alues 5 and V alue 6 m ay e ach b e identified by a tag, which tags may be for explanatory purposes and may be denoted TAGV5 (e.g., <Answer Tag="TAG-V5">) and TAGV6, respectively. A more complex computation 404 may be any function f which may be required of the security system and capable of calculation, and may use visible values and invisible values. The result of function f may be directed to a required or requested location, such as the placement of the result as Value 6 in this example. This may be coded, such as in the above example, as <Answer Compute="TAG_V5 * TAGV6">. Returning now to Figure 1, Risk Categories 102 may categorize risks into various groupings to address certain objectives, and may be in accordance with tolerable risks for one or more business processes. As an example, in [BS 7799], information security is characterized as the preservation of confidentiality (C), integrity (I) and availability (A). It is common in risk management applications that a system may be evaluated separately based on various unique or applicable criteria and such an evaluation may be analyzed simultaneously. In the aforementioned BS 7799 example, using grades for Confidentiality, Integrity or Availability, the controls necessary to satisfy each criteria may be different, and in fact, may in some cases conflict. For example, in container shipping it is expected that evaluation of processes that control loading of goods, and sealing of goods into containers, would be evaluated under separate and distinct, and possibly conflicting, risk related criteria. 15 WO 2005/124622 PCT/US2004/029364 Without limitation, Risk C ategories r eferenced in F igure 1 may be specified in XML, or a similar schema, for example. For example, an XML coding for such risk categorization might include: <RiskCategories> <Category Name="Confidentiality" Description=:"For privacy protection"> <Category Name="Integrity" Description="For modification of data"> <Category Name="Availability" Description="For ability to use resource"> </RiskCategories> However, Risk Categories may be an aggregate calculation of risk to some attribute of risk, rather than a specific risk aspect of some attribute of risk. T hus, the aggregation may be one to one 106, many to one 109, or one to many 105. As such, the exemplary XML-A discussed hereinabove may be modified as: XML-B <Question ID="3" visible="yes" Text="Are Fences higher than 10 feet?" Type="integer"> <Answer ID="1" Text="Yes"> <Risk Name="RiskCatl" Script="Add(50)"> <Risk Name="RiskCat2" Script="Add(20)"> </Answer} <Answer ID="2" Text="No"> <Risk Name="RiskCatl" Script="Add(l 0)"> <Risk Name="RiskCat2" Script="Substract(l 0)"> </Answer> </Question > In XML-B, if question 3 has a response of Yes, then 50 is added to RiskCatl and 20 is added to RiskCat2. Note that subtraction, addition, division, multiplication, multiplication by constants or factors, or other calculation functions may be used, as shown in Answer ID ="2". Additionally, calculations may occur in stages. For example, if answer A is yes, multiply by 3, if the result is greater than 50, ask question B, and if the response is answer C, subtract 3. Further, data from one, or many, or other sources may be drawn upon in the performance of such a calculation. For instance, a function F may be performed on the input value (e.g., "Add (thisInput*5)"), the response (i.e., thisInput) may be multiplied by 5, and the result may be added to an appropriate Risk Category. 16 WO 2005/124622 PCT/US2004/029364 Functions may be complex, and may include other programming aspects, such as incorporating a programming script using Java or another high level language, for example. Without limitation, a programming script or calculation may specify tag names, such as "CountryValue" described in XML-A, within a function to represent a value, or as an index to locate a value, such as a value in a database or web location table, for example. Risk Categories may be analyzed pursuant to one or more risk Policies 107. Thereby, Document 101, and more specifically the values of a document 101, may be rated against a risk Policy in accordance with one or more requested risk policies. In the following example, multiple rules may be applied in which the "Action," a script using a specialized language or known language, such as Basic, Visual Basic, C, C++, Java, or Perl, for example, is performed when the "Criteria," a script returning true or false, is assessed. As will be apparent to those skilled in the art, the following example is not limited to a particular language, and may additionally be performed, for example, in XML. Name: <policy name> Rule: <label> Criteria: <conditional script> Action: <script> Policy-Rule: PolicyName: SilverBuilding Rule: RequireSupervisor Criteria: ((Riskcatl > 50) or (Riskcat2>1000)) and (riskcat3>5) Action: Require("Supervisor", RED); exit Rule: EmailCommerce Criteria: ((Riskcatl > 20) or (Riskcat2>100)) Action: Notification (email, "warning@commerce.com", "Review Company X Warning logs") Rule: Accept Criteria: Null Action: Accept("1 June 2004") The above example is followed herein from top to bottom. Some of the functions of note may include, by way of example, but may be not limited to: 17 WO 2005/124622 PCT/US2004/029364 Exito: exit and do not test against any additional rules; Require(<Group>, <FLAG>, <effective date>): acceptance of the Document requires someone from group <Group> to accept. The user may be provided a FLAG value (e.g., RED condition) to help understand the severity of the problem, and <effective date> may state the effective date for the acceptance by the user of the Document (i.e., how long the acceptance is good for) once a user of Group has accepted the Document; Notification (<type>, <user name>, <subject>, <Body>): send a notification to < user name> with Subject <subject> and Body <body>. Types of notification may include, but may not be limited to email, calendar, fax, automated telephone calls, and other forms of notification systems, for example. Emergency notification may call government agencies (e.g., like a "911' call) for first responder actions, such as by law enforcement, transportation, commerce, military or other agency, for example; Schedule(<date/Time>, <actions script>): this may schedule the action script to be performed at a specific data and time (i.e., <date/Time> field) . For instance, a transaction may be initiated or notification may be set after a specific time; Accept(<date>): instance may be accepted against Policy and may be effective until and including the date in date field; Store(<valuel>,<locationl>, < value2>, <location2>, .): may store value into location, value2 into location2, etc. Locations may be database fields, for example. Store may also be to local storage or inter- or intra- data stores, for example (see Figure 5); PushPolicy(<policy description>: this may push a Policy into the present system or off to another system. For example, satisfaction of a certain se t o f c onditions m ay cause a Policy change on an RDS instance processing for other RDSs; CreateTransaction(<transaction type>, <recipient>, fieldd1, valuee1, ...): this may be similar to PushPolicy. Create transaction may transmit a transaction Document to recipient of the form transaction type. The data fields for the transaction may place value into field. As will be apparent to those skilled in the art and in light of the disclosure herein, specialized scripts and other forms of programming languages may likewise be used in the present invention, such as to allow for more sophisticated and complex coding of criteria and rules. Such additional complexity might include, for example, looping structures, including external to internal and internal to external looping, access to 18 WO 2005/124622 PCT/US2004/029364 external data, including external specialized scripts, initialization values, and other complex conditional statements. Policy templates may provide suggestions, changes, modifications, or generally accepted practices to allow for generation of risk policies, or to allow for transference of data for use as inputs for risk policies. For example, policy data may take numerous forms, as will be apparent to those skilled in the art, and policy templates may provide for the transference of one form to another form. Hereinbelow is an exemplary illustration of a "trigger policy" Policy template, illustrated using XML: Trigger-Policy <TriggerPolicy> <Event ID="1" Document="BuildingSecurity" Criteria=" CountryValue = "Korea"> <Policy Name="GoldBuidingAsia"> <Policy Name="SilverBuilding"> </Event> <Event ID="2" Document="BuildingSecurity"> <Policy Name="GoldBuiding"> <Policy Name="SilverBuildingAsia"> </Event> <Event ID="3" Document="FacilitySurvey"> <Policy Name="SurveyPolicy"> </Event> </TriggerPolicy> For example, in the exemplary "BuildingSecurity" Document (see examples XML-A and XML-B hereinabove), the Trigger Policy Template may first check if the Country value matches "Korea." If it does, then the policies GoldBuildingAsia and SilverBuilding may be tested against the Document. If it does not, then the policies GoldBuilding and SilverBuildingAsia may be tested against the Document. Policy templates, such as Trigger-Policy, may also create or incorporate other Document-Instances. For example: <Event ID="1" Document="BuildingSecurity" Criteria="CountryValue = Korea"> <Replace Document="KoreaBuildingForm"> 19 WO 2005/124622 PCT/US2004/029364 </Event> <Event ID="2" Document="KoreaBuildingFonn" Criteria=" CountryValue = "Korea"> <Policy Name="GoldBuidingAsia"> <Policy Name="SilverBuilding"> In this example, the BuildingSecurity Document may be converted into a new Document, KoreaBuildingForm. The new Instance of the form KoreaBuildingForm may be run through the trigger Policy. The mapping from BuidlingSecurity to KoreaBuildingForm may be achieved in a variety of ways, as will be apparent to those skilled in the art. Mapping from a tag value to a tag value may be an exemplary approach for information transference using policy templates. For example, a country value may exist in two forms, and the policy template mapping may be done one to one. As used herein, an instance of Document 101 may be an approved instance or a disapproved instance. A Document Instance may be an approved D ocument i f one o f following two conditions is true: (1) Accept () is performed; (2) Requireo is performed, which may include that a member of the Group specified in Requireo has approved the Document. Computation 108 may illustrate an example of the computation of a Risk Category. The method of computation may be, for example, complex, entity specific, or generic and non-entity specific. F or simplicity, in this example, e xemplary operations may be of the form: F( g (Value) , h ( Value, Value ') ) = Risk Cat value, where F is a mathematical summation of the input values. In this example, g and h may be various algebraic functions, such as if (value = True) then return 50 else return 100. Similarly, multiple choices may be generalized. For example, a computation may return (value * constant), where constant is a predefined integer. Thus, the values g and h may be or require one or multiple inputs, which may be external, such as data inputs responsive to questions, or internal, such as application of a constant to data obtained, as in computation 108 for h. Figure 2 is a flow diagram illustrating the application of a plurality of risk policies. D ocument Instance 202 for document 101 may represent, in this example, a "filled-out form" for a specific input instance. The illustrative Document Instance 202 is weighted 205 against one or more Risk Categories, wherein Risk Cat Value x, y 20 WO 2005/124622 PCT/US2004/029364 represents the value for Document y under Risk Category y. Thereby, with respect to specific exemplary Risk Policy 201, Document Instance 202 may be Approved, such as approved via the AcceptO function, or via the Requireo function after the user from the Group accepts the Document Instance, or disapproves. Document Instances 202 may be approved under m ore than o ne P olicy 203, 204 b efore ultimate approval, such as in a hierarchy of risk policy applications to a given document 101. In the exemplary embodiment of Figure 2, risk policy 203 may demonstrate a Document Instance accepted under only one Policy, and risk policy 204 may demonstrate a Document Instance approved under more than one Policy. It should be noted that, in the example of XML-B, the Risk Category (RiskCat)Values may be dependent on the Document, and the same Document Instance may not generate multiple RiskCat values, such as those that, for example, might be associated with different Policies. However, the same Document Instance may be evaluated under two different policies by deeming the Risk Category to have different values under each Policy. For example, a company may have an internal confidentiality policy and an external confidentiality policy. Such a policy could be that any confidential digital data leaving the organization must be encrypted while in transit, whereas internally transmitted data need not be encrypted. A Document may thus specify whether data leaving an internal server is encrypted. Thereby, for the internal policy, the "confidentiality" Risk Category would generally not affect transmission from the internal server to that or another internal server. However, an answer of "NO" with regard to encryption for that document would affect the risk for the "confidentiality" Risk Category if the attempted transmission was external. Thus, in this example, the confidentiality Risk Category score may have different results under different policies. This restriction in exemplary XML-B may simplify evaluation by reviewers that may understand a Risk Category to have only one meaning. Such a restriction with regard to risk categories is exemplary only, and need not be used in the present invention if necessary. In such an exemplary approach, risk value evaluation may be limited to that specified in a Policy-Rule. A risk policy reference may be incorporated into XML-B as follows: <Risk Name="confidentiality" policy="confidentiality-external" Script="Add(5)" 21 WO 2005/124622 PCT/US2004/029364 <Risk Name=="confidentiality" policy="confidentiality-intemal" Script="Add(0)" Document Instances may have an approval in relation to a Policy. Similarly, Policy and Qualification may be linked. Figure 3 is a flow diagram illustrating the relation between policy and qualification. A set of Documents 305 may be related to a policy or a set of policies 301 via relation 306. Policies may be specified in a hierarchical nature. For example, a "gold seal" (i.e., a high level on the hierarchy) may not require certain checks on shipments that would otherwise be required against a lower level on the hierarchy. S imilarly, this may b e done o n Qualifications. As may be seen, the same approach may be taken to classify assets upon evaluation, with ones meeting certain criteria as being "gold seal." A ship - a Transport may be owned by a company which is itself an "Infrastructure Asset". Naturally, there is an "owner of' relationship in one direction, and "owned b y" in the o ther, for m any e xemplary a ssets. A ssets m ay have relationships that may be relevant to evaluating the risk of any particular transaction. These relationships, which may be one to one, one to many and/or many to many, may be used to evaluate risk. As an example, a port may be evaluated against physical security. Relationships may show that part of the physical security for a port is "managed by" another entity. The "managed by" entity may also be evaluated and its risk appropriately calculated into the port's risk. A Qualification 302 may relate to one or more Policy Instances 301. For example, Qualification 1 302 and Qualification 2 may be earned if a Document Instance 101, or a document instance set 305, is approved against Policy 1. A Qualification may require more than one Policy approval 304. In this example, a Document Instance must have approvals for Policy 2 and Policy m to earn Qualification 3. Thus, there may be present a layering between Policy and Qualification. As discussed hereinabove with regard to the hierarchical nature of Policies, Qualifications may likewise be hierarchical, both with regard to other Qualifications, and with regard to Policies. A Qualification may be coded, such as in XML, as shown: QUAL-Template <Qualifications> <QUAL Name="GoldSeal" Description="Corporate Gold Seal for Vendor"> </Rules ID="1I"> <Cat ID="1" Name="GoldPolicyPhysical"> 22 WO 2005/124622 PCT/US2004/029364 <Cat ID="2" Name="GoldPolicyProcesses"> </Rules></QUAL> <QUAL Name="SilverSeal" Description="Corporate Silver Seal for Vendor"> <Rules ID="1"> <Cat ID="1" Name="GoldPolicyPhysical"> <Cat ID="2" Namne="SilverPolicyProcesses"> </Rules> <Rules ID="2"> <Cat ID="1" Name="SilverPolicyPhysical"> <Cat ID="2" Name="GoldPolicyProcesses"> </Rules> <Rules ID="3"> <Cat ID="1" Name="SilverPolicyPhysical"> <Cat ID="2" Name="SilverPolicyProcesses"> </Rules> </QUAL> </RiskCategories> In the above example, Qualification "GoldSeal" may only be earned if GoldPolicyPhysical and GoldPolicyProcesses may be achieved. However "SilverSeal" is earned if either GoldPolicyPhysical or GoldPolicyPhysical is achieved, and similarly SilverPolicyProcesses or SilverPolicyPhysical may be achieved, but not if both GoldPolicyProcesses and GoldPolicyPhysical may be achieved. Figure 15 simplifies the exemplary illustration of Figure 4. As illustrated, a Document Instance may relate to multiple inputted "Documents" that have been inputted at different times. For example, Document A (values below line 6002) may have been received at time=0 and stored in database 6004. At time=1 Document B (values above line 6002) may be received. Document A may be placed in a Document Instance 6003. The Policy evaluation discussed hereinabove may be part of a Risk Detection System (RDS). A RDS may exist within a larger infrastructure, as is illustrated in Figure 5. The RDS may evaluate Policies against Documents, maintain storage to evaluate Policy 507, and determine Qualifications. The RDS may be linked to one or more Aggregators 506. Aggregators may include an RDS that takes information from multiple RDSs, and feeds policies and Documents to other RDSs. If two Documents appear at two 23 WO 2005/124622 PCT/US2004/029364 RDSs, the Aggregator may include a reconciler, such as an Intra Global Database 502. An A ggregator m ay d ynamically generate o r apply P olicies partially based on history. For example, if multiple inputs into an Aggregator from discreet RDS instances indicate excess exposure to country risk, the Aggregator may modify the Policies in various RDSs to control the risk. For example, post-modification Documents representing transactions may not be accepted by the modified Policy because the acceptable threshold value for country risk may have been re-set high, thereby precluding acceptance of previously acceptable Document scores. As the RDS and Aggregator may receive information from an Intra Global Database, and may obtain information from an Inter Global Database 502. Inter Global Databases may be outside an organization. For example, the Bureau of Customs and Border Protection, an external organization, may have "watch lists" for persons or entities that it recommends no business be done with, as well as controls, such as handling requirements, for specific classes of cargo. The U.S. State Department maintains a known terrorist list, and other government agencies and institutions, regulatory and standards organizations, partners, and various other providers also maintain data useful for an RDS. Some companies may also provide statistical and other data useful to dynamically and pro-actively generate policies. As such, information may be distributed to systems and trust levels may be established. Trust manager 503 may represent a security trust system, such as a Public Key infrastructure (PKI) [X500,X509, RFC3280] or Kerberos [Neuman] or other means known in the art [Menezes]. Trust Managers may be managed by an inter- or intra Regulatory Organization. A Regulatory Organization may be any person or group that regulates those approved to communicate within an infrastructure, and may regulate what rights those approved communicators have. A Trust Manager may make security scalable. However, the infrastructure of Figure 5 may not require the use of Trust Managers, as security may be established directly, such as with the physical exchange of cryptographic keys, or by other methods known in the art. Entry Points 501 may be sources where data is received. An RDS may receive data directly from, or in c ombination with, an Entry P oint. Entry Points may also be probes in an intrusion detection system. Entry Points may reduce cost, by only receiving data and place data at an RDS or at an Inter- or Intra- Global Database for an RDS or 24 WO 2005/124622 PCT/US2004/029364 Aggregator to use. Entry points may be specialized and may be used to offload workload from the RDS. For example, XML-B hereinabove may include Policy enforcement, although an Entry Point may do some level of Policy review of Documents. This reduces the risk of outsiders discerning the Policy of the RDS. Entry Points may also establish trust directly, or via a Trust Manager 503. Figure 6 is a flow diagram illustrating the secure transmission of a Policy Template, Policy-Rule, or Policy Template for a Qualification or a Document, such as XML-A or XML-B. A Template 605, for example, may be transmitted 602. The sender may be an Aggregator, an RDS or a Regulatory Organization, for example. Trust Manager 604 may establish trust between the RDS and the sender 603. As an example, if the Trust Manager is a PKI and messages sent by the sender are signed, the RDS may validate the signature based on a certificate. The RDS, which may also be an Aggregator, may receive the Template, which may be authenticated, and may incorporate the Policy Template into subsequent evaluations. Policy Templates may be generated by different organizations and components within an infrastructure. Precedence, i.e. the order of an evaluation, may be specified, as shown in Figure 7. In the example of the Policy-Rule application hereinabove, the Policy may be evaluated "top down". Policy 702 may also be made up of sub policies. For instance, Policy 702 may be perfonned. before Policy 703. Some organizations may be placed higher, such as wherein government agencies may take precedence over corporate 703 or locally defined entities or persons 704. An organization may also specify precedence in its Policy Template. For example, Rule: <label> Priority: <High=l to Low=10> Criteria: <conditional script> Action: <script> In this example, a government agency may place multiple Templates into the RDS and these may be given priority over other sources 702. Access to an RDS may be allowed for various organizations. Access control may restrict access to information, or the modification of information, based on who the user is and how that user is identified. Figure 9 depicts a user 905 having access 906. The user 905 may belong to an Inter Regulatory organization or Intra Regulatory organization 902. 25 WO 2005/124622 PCT/US2004/029364 Trust relationship 903 depicts trust between Trust Manager 904 and the regulatory organization 902, and trust relationship 907 between the trust manager 904 and the RDS 901. Trust may be imposed between Trust Manager and the user through mechanisms developed for computer security. Such examples include Registration Agents within a PKI, acting on behalf of the regulatory agency, to validate users, and the process for the certification of user public keys. Based on the trust relationships established via the Trust Manager 904, the user may have specific access rights to the RDS, and may have access rights to an Aggregator, or Global Database, based on the rights provided to that user via some access control mechanism. A government agent or partner may have restricted or expanded access, while internal users may have different access rights. For example, a government agent may be automatically granted certain access rights to otherwise restricted data and data stores, conditioned upon the occurrence of a defined event and presentation of appropriate credentials, including provision of on-line evidence of identity or role. An RDS may communicate with another RDS to provide Instances or Templates of policies, Documents and/or Qualifications. RDS1 801 may send an object to RDS2 802 or Global Database data 806, 803, 804. Send 803 or 804 may be authenticated, such as being digitally signed, or sent via secure tunnel, such as via SSL, VPN, IPSEC, or the like, or by some other secure means, as may be known to those possessing an ordinary skill in the pertinent art. Security may use or be established through a Trust Manager via trust relationships 805 to the send 803 and 804. Relationship 805 may represent a certificate relationship by Trust Manager acting as a certification authority (CA) in a public key infrastructure (PI), for example. Figure 8 depicts a push approach in which the RDS pushes out the various Instances and reports in a secure manner, such as the Instance signed with a public key certified by the Trust manager acting as a CA. In practice, the RDS need not require a push approach, but rather may present information locally in response to information being pulled. That is, it may provide a pull rather than a push. Hence, RDS application 802, 806 may make the request and receive the data locally 801. The data that an RDS or, similarly, a Global Database or other data store, such as a file, directory, or the like, presents externally may be useful to the users. In Figure 8, several types of information may b e presented. R eporting may b e, for e xample, audit logs, aggregated risk exposures, anomalies found, and other events that indicate an 26 WO 2005/124622 PCT/US2004/029364 auditable condition. Reporting may allow external parties to review procedures being used, although specific audit level access rights may also be required. Qualification Templates, Policy Templates, or Document Templates may allow for an RDS to send Templates for external review or to be implemented by another RDS. The RDS may support various Roles. Those roles may include: RDS Administrator: performs basic management of the system such as, but not limited to, providing access to users, i.e. ID management, groups and external components; monitoring the performance of the system; ensuring backups may be performed, and other basic tasks not generally related to the risk that the system is monitoring; Template Creator: create(s) the various Templates used in the application including Policy, Document and Qualification Templates; Data Entrant: submit(s) data into the system. There may be different categories of data entrants with differential rights, for example, some may be permitted to fill out some forms and not others, or only fill out forms for specific groups; Risk Manager: specifies Policy tolerances for Risk Categories and Qualifications, how the Risk Categories may be determined, and the actions the policies perform against the various categories; Document Approver: approves a Document Instance against a Policy when a Required action has been set that requires acceptance of a Document, either for each Instance or for some defined group or groups of Instances; Supervising Approver: special groups of Approvers. Some organizations may require an Approver as well as a Supervisor for Document approval; and Auditor: have read-only access to review the actions of others. Roles may be performed, at least in part, by computer systems. For example, Templates may also be created by RDS and Aggregators, and Data Entrants may be Entry Points. Risk Managers may be a special type of Template creator that may be, for instance, the RDS or Aggregators. These may review past actions to determine Policies for future actions. In an intermodal container shipping exemplary embodiment of the present invention, categories defined may include Infrastructure Assets, Transport Assets, Shipment Articles, and the like, and each category defined may have documents, and/or values, expected to correspond thereto or be representative thereof. Infrastructure Assets 27 WO 2005/124622 PCT/US2004/029364 may be documents that relate to the infrastructure used for the movement of intermodal containers from point to point, including from point of loading to point of unloading. Examples of Infrastructure Assets may be computer systems, information processing systems, warehouses, terminals within ports, and the like. Infrastructure Assets may not only be limited to physical entities or things, but may be legal entities as well. For example, the company owning and/or managing a warehouse may be classified as an Infrastructure Asset. Transport Assets may be documents that are assets directly used for the physical movement of Shipment Articles, but which may not be part of the shipment. For example, a train engine, container or other ship or aircraft, used for the specific purpose of moving Shipment Articles, may be a Transport asset. If it is difficult to determine whether an asset is an Infrastructure or Transport Asset, it may be treated as both. Shipment Articles are documents that may be the actual shipped goods, and specific assets and documentation used in or related to the movement of those goods. This category may include, but may not be limited to, the containers that bound the physical shipments, seals that may be barrier or indicative, or manual or electronic, the modification of the shipment, and documentation related to the specific shipment, such as shipping instructions, bills of lading, and the like. Surveys, questionnaires and/or other mechanisms may be used to identify Infrastructure Assets and other aspects of those Infrastructure Assets, such as persons who may be in some way accountable for the Infrastructure Asset. Infrastructure Assets may have sub-parts, systems or components. For example, a building may be an Infrastructure Asset. However, the storage facility located within the building, but subject to different physical, logical or legal controls may be treated as a subcomponent of the building but still classified as an Infrastructure Asset. Infrastructure Assets may be evaluated, based on the type of facility, against different criteria including, but not limited to: Controls o n p hysical s ecurity (e.g., t ypes o f locks, h eight o f fences, number of security guards, etc.); Controls on personnel security (e.g., background checks, employment contracts, etc.); Controls on data systems (e.g., confidentiality, integrity and availability, etc.) Historical controls (e.g., prior history to determine if fixed assets perform appropriately); 28 WO 2005/124622 PCT/US2004/029364 Insurance (e.g., kinds of insurance and its limits); Prior-legal and /or regulator actions against the asset (e.g., have there been or may be there existing legal or regulatory actions initiated against the assets, judgments, injunctions, verdicts, consent decrees, etc.); Contractual controls (e.g., contractual provisions regarding the Infrastructure Asset, its workers or plant, etc. ); Vendor controls (e.g., who they are, how they have been evaluated, etc.); Record keeping and auditing controls (e.g., m ethod o f r ecord k eeping, types o f auditing controls, etc); and Procedures and practices (e.g., methods for accomplishing tasks). These criteria, or a composition or decomposition of these, may be treated as Risk Categories. Additional Risk Categories may be included as necessary. The nature of the asset being evaluated may determine the Risk Categories used to evaluate it, as well as the choice or weighting of the data values, used to calculate the Risk Category values. Thus the questions composing the Physical Security Risk Category for a low value warehouse may be different than those composing the same Risk Category for a high value data center, for example. An asset may be entered for use by an RDS in multiple ways. It may be entered using a web system, or another application may inform the RDS of a new asset, for example. There may be specialized RDSs for entry of assets of one or more types. These may then provide data related to the asset to other RDS systems. The new asset may reach another database such as, for example, a vendor database. The fixed asset information may come from, for example, an Aggregator, another RDS, Inter- or Intra Data Stores, or other sources. Information may also be obtained from, for example, field work, surveys, government forms, or other data, whether internal or external. Once an asset is defined as a document, an evaluation may be made based on the appropriate Policy. Introduction of a new asset may be a triggering event, such as a new vendor transaction, such as a web-based entry, and the triggering event may cause evaluation against a trigger Policy. This evaluation may create multiple actions as part of the Policy, for example, a) it may require certain surveys (e.g., physical building survey) to be performed and, therefore, notifications to be sent to appropriate people to inform them a new vendor has been initiated and that they must complete a survey, b) internal 29 WO 2005/124622 PCT/US2004/029364 and external data vetting may be initiated (e.g., check denied party lists, check any legal/regulatory actions, validate insurance policies, financial status, etc.), such as an external p arty e valuation (e.g., initiate p urchase o f a third p arty t o d o a s ite s urvey o r other analysis). As more information is received, it may be tested against the Policy by the Trigger Policy. As more information is received, the Policy may be satisfied as to some cases, and Qualification of an asset may be achieved in the satisfied cases. Moreover, asset Qualification (which may be of Transport, Infrastructure or Shipping Articles as well as shipments themselves) may be a precondition to other o currencies, such as in the supply chain wherein a shipment is booked; carriage of a shipment by a carrier on either a direct booking basis from the shipper or as one received from, for example, a non-vessel operating common carrier; pricing for carriage; delivery times promised; insurance coverage of the goods carrier or of other assets used to carry, handle, pack or store the goods. Approval under a Policy, similar to a Qualification, may be short term. For instance, a short term approval may be provided if there is a material but not significant impairment to, or lack of, an anticipated control. For example, a Physical Security Policy for buildings may change. B buildings meeting c ertain secrecy criteria m ay only accept locks accepted under a previous Physical Security Policy for up to one month. After one month, a short term approval may no longer be valid. Approved Shipment Articles, in the form of documents, may include the goods being transported, packaging thereof, an intermodal container the goods may be transported within, and various security, visibility or status devices for the container for the goods, and shipment related documentation or messages (e.g. a bill of lading or an advance shipping notice). Shipment Articles may be part of what is evaluated in the risk management evaluation of a particular shipment and, in particular, the containers within it. As will be apparent to those skilled in the art in light of the teaching herein, the risk profile of a particular container may be affected by a number of factors such as, among other things, the location or ownership of a facility or conveyance where the container is stuffed, stored, moved with or moved through; the backgrounds of any persons with access to a container or the goods that were stuffed in it anywhere along the path of travel; the policies, procedures and practices in place to prevent or detect unauthorized additions to or deletions from cargo; or tamper evidence data taken directly 30 WO 2005/124622 PCT/US2004/029364 from the container while in transit. The data associated with the above factors may be held by a number of different entities; yet, all of it may be important to determining whether a container should be permitted to be laden upon a container ship, delivered to a port, or released from a government's custody. Moreover, determining aggregate risk through analysis of the risk profile of a single container may not be sufficient. Relationships amongst multiple c ontainers and other factors may be necessary to determine the overall risk of an undesirable event, such as terrorism where a terrorist has may have sufficient knowledge to split shipments constituting attacks into multiple containers each of which individually may appear benign but in combination which may result in a threat, for example. The effort to implement collaborative risk management in a supply chain context may be complicated by the fact that certain of the participants in a single supply chain may be competitive with one another. For example, it is embedded in the ocean carriage business model that carriers, NVOCCs, consolidators and others book container passage with carriers either on a spot basis or pursuant to forward contracts. A booking entity may desire to withhold information from the carrying entity, particularly customer data, for fear of circumvention, such as the carrying entity attempting to circumvent the booking entity and communicate directly to the customer. Areas of risk and risk information repositories and approaches may include the following: The risk postures in all or some of various dimensions (e.g. physical, logical, financial, etc.) of the Infrastructure Assets or Transport Assets (including accountability programs for all supply chain phases, addressing workers and business property) may be used to collect, manufacture, package, load, seal, move, etc., the Shipment Articles; Screening to Inter- or Intra- Data Stores for relevant information about Infrastructure Assets, their ownership or other material "related-to" relationships that could impact risk; The c onditions under which the container m ay b e loaded and sealed, including inspection, loading and documenting procedures of various types, use of independent inspection agencies, physical access controls, logical protections, etc.; Positive and negative rule sets for containers related to, among other possible parameters, trip duration, weight, time, location, state, etc. and other associated risk management rules and exception procedures, for example: 31 WO 2005/124622 PCT/US2004/029364 No more than a certain period of time; No shorter than a certain period of time; No further than a particular measured distance; At least as far as a particular measured distance; Variation from an expected route whether on a road or on water; Prohibited locations, including determination by GPS tracking; Expected locations, including determination by GPS tracking; Documentation anomalies such as inappropriate source or destination based on origin or season; Door open or light content rules for sensors or seals; Unexpected nuclear, biological or chemical materials; Unexpected temperature changes; Unexpected gas content such as C02; Analysis for anomalies of shipment or container related status messages that may already be provided among supply chain participants; and Analysis of shipment related Documents (other than status messages) for anomalies. It should be noted various incidence histories and Signature Templates, as well as the r eporting function, in ay b e independent s ervices in the p resent invention. That is, knowing that some aspect of a system may be approved by some approving agency or person may be valuable. As an example, a vendor may be approved against a Policy by an institution. This approval may be incorporated into an RDS. The approval incidence may be signed, or have other security controls placed on it. A company may purchase an approval incidence, such as wherein the regulatory agency sells approvals as a means to fund itself, or may be permitted to sell the approval incidence, or some aspect of it, to a third party. In a specific exemplary illustration of risk management in a collaborative shipping environment, as illustrated in Fig. 10, a document is provided having values therein. The values may be scored in accordance with one or more risk policies, which policies may be resident in one or more risk policy templates, as discussed hereinabove. The risk analysis may be perfonned in accordance with multiple scoring mechanisms. For example, financial institutions may score a document and its values in one manner, while insurance institutions may score the same document and its values in a different manner. 32 WO 2005/124622 PCT/US2004/029364 In such an exemplary embodiment, a global supply chain risk may be evaluated. For example, a warehouse in the supply chain may include a great plurality of documents having a great plurality of values. These documents may be categorized in accordance with a risk for the documents in each category. For example, warehouse security may form one category, and power supply may be another. The risks may be analyzed against a risk policy based on values. For example, a document for warehouse security may include the value "cameras present: yes". Obviously, such a value may substantially affect the application of the policy for warehouse security, and whether the security passed or failed, or reached a certain qualification, based on application of the risk policies to such a value. Further, one or more associations may be provided as a value that may affect risk. Associations available for relationships that may affect risk may include, for example: Owned by; Lessor of; Lessee of; Customer of; Vendor of; Supplier of; Managed by; Regulated by; Insured by; Audited by; Evaluated by; Inspected by; Audited by; Operated by; Processes for; Financial institution for; Insurer of; Guarantor of; Security for; Related to (when association type is not specified in system); and The inverses of the above (e.g., Owned by inverse is owner of). As such, this exemplary link in the supply chain may be scored for each category, and for overall categories, according to values within documents. The risk analysis, and the overall risk analysis, may follow one or more templates. For example, if the warehouse is present in a first country, where crime is high, an overall score of 80, or a security score of 85, may be unacceptable. H owever, if the warehouse is present in a second country, where crime is low, an overall score of 70, or a security score of 75, may be deemed acceptable. As may be seen in Figure 10, system 1000 includes a central node 1001, at least one ancillary central node 1002, at least one first tier company 1003 and at least one second tier company 1004 communicatively coupled via aggregation nodes 1005 and at least one aggregation node of last resort 1006. The government is also shown, as will be discussed in more detail hereinbelow. System 1000 may be an aggregation of all nodes, which may be bound by some type of arrangement, such as a contractual network, and which share risk related data resident in documents pursuant to the rules governing system 1000. The rules of system 1000 may be based on document-defined relationships, such as contractual relationships 33 WO 2005/124622 PCT/US2004/029364 that define, at a minimum, one or more operational procedures, risk standards, and response protocols. Central node 1001 may be the top level entity within system 1000. Central node 1001 may be responsible for, among other things, disseminating, or permitting dissemination of, risk policy for all nodes within the domain of central node 1001. Central node 1001 may further act as the information aggregator of last resort for commercial privacy purposes. Central node 1001 may be composed of a single entity as shown in Figure 10, or may be a group of entities working in concert through some known mechanism or arrangement. Central node 1001 may interface with other ancillary central nodes 1002 that perform certain functions, such as making a detennination regarding insurance or other specialized or subject matter expertise. Central node 1001 may also be defined against well defined functions or against roles within a system. For example, an insurance company may define a central node CN1 to insure its policy holders and a central node CN2 may be for another Insurance policy, while central node CN3 may be an industry association which specifies and monitors specific member controls to obtain, for example, preferred regulatory treatment. Moreover, CN1, CN2, CN3 may be working within a global CN-GLOBAL that covers all entities. By way of a further non-limiting example, central node 1001 may perfonn a self-monitoring role within the system and determine whether certain portions of system 1000 have been corrupted or have inappropriately changed state, and may respond with appropriate action. For the sake of clarity and ease of understanding, the present invention is discussed utilizing a single central node 1001, while it is understood that any number or any combination of central nodes working in concert may similarly be used. Participation of entities in system 1000 may or may not be tiered, with differently tiered memberships having different requirements or privileges. While Figure 10 shows a tiered environment, it would be evident to one skilled in the pertinent arts that a single tier may be used. In an embodiment of the present invention using tiered environments, lower tiered entities may be brought in by one or more higher entities in the chain through the rules specified by central node 1001. According to an aspect of the present invention, there may be two tiers 1003 and 1004, one consisting of larger companies with highly automated operations, and a second layer of smaller companies that use the technology of others, including first tier companies 1003, on an outsource basis. For example, 34 WO 2005/124622 PCT/US2004/029364 according to an a spect of the present invention, major carriers may b elong to first tier 1003. Smaller companies which obtain booking or track and trace functionality from the major carriers may be second tier companies 1004. As may be evident by those skilled in the art, any number of tiers may be used. Central node 1001 may be responsible for identifying the appropriate characteristics of any tiered membership. As part of its function, central node 1001 may define one or m ore se ts o f d ata elements that must be used to form a document that constitutes a set of information, preferably a full s et, for r isk m anagement p urposes. For example, in regard to cargo, aggregation node(s) 1005 may take responsibility for the aggregation of risk related information across the population of participants involved in a particular shipment. Aggregation node 1005 may be any entity within system 1000 that aggregates risk related information from at least one entity other than itself. A party in system 1000 may object to a particular aggregation node on the grounds of commercial privacy or other similar reason. Upon objection, which may be recorded or understood in many ways that will be apparent to those possessing an ordinary skill in the pertinent arts, aggregation node 1005 for that information shifts in a fashion defined in the system rules, possibly until central node 1001 acts as the neutral aggregation node of last resort 1006. Referring now also to Figure 11, there is shown a diagrammatic representation of the standards creation and implementation of the system of Figure 10. As may be seen in Figure 11, system 1000 may further include at least one standards organization 2001 (which may include the government, for example), a set of global standards 2002 developed through the interaction of at least one standards organization 2001 and central node 1001, and processes and procedures 2003 developed according to the system rules. The standards promulgated by central node 1001 may be acceptable to other stakeholders in the system, such as national governments concerned with border policy, non-governmental organizations that have undertaken to draft supply chain related risk or security rules in conjunction with governments or other parties, insurers, financiers, and others who may be asked to take on security obligations or risk transfer within the supply chain, for example. Central node 1001 may be responsible for adopting policy and standards for system 1000 as promulgated through the system rules. Central node 1001 may negotiate with standards-making stakeholders to obtain a globally acceptable set of standards 2002. 35 WO 2005/124622 PCT/US2004/029364 Central node 1001 may further be responsible for developing processes and procedures 2003 for bringing entities into system 1000 through bilateral execution of documents in the form of contracts that bind each entity to the system rules. System 1000 may contemplate criteria for participation eligibility within system 1000, which may be developed by central node 1001 and the members, standards organizations 2001, or external entities, such as government regulators. Referring now to Figure 1 2, there i s s hown a p rivacy, compliance, aggregation and p ayment r epresentation a according t o an a spect o f t he present invention and to the system of Figure 10. In an embodiment of the present invention, an NVOCC may be hired by a booking entity, which may be the entity in an international trade transaction that takes an order to book passage of a container or other cargo, for example, for a particular container headed to the United States. In this role, the NVOCC may have certain customer information that it prefers not to provide to the carrying entity 3001, the entity that operates the transporter of the cargo. Carrying entity 3001 may require that the customer name be screened against denied party lists prior to agreeing to carry the container. Carrying entity 3001 may also have a responsibility to submit the identity of the customer to a government authority 2001, such as the United States Bureau of Customs and Border Protection, for example, through an electronic interface 3007. Such an advance manifest system 3002 may be created to comply with the U.S. 24 Hour Advance Manifest Rule, or other similar rule known to those possessing an ordinary skill in the pertinent arts. Within system 1000, carrying entity 3001 may be required either to review a document having data that demonstrates values evidencing compliance with its security requirements by booking and tracking entities, if those entities are not identical with carrying entity 3001, or it may be required to rely upon a liability backed representation 3003 that the representing entity is in a compliant state. Central node 1001 may also, in the alternative, make the r epresentation 3 004 v ia one o r m ore d ocuments having values to the relying entity. Central node 1001 may define instances in which it is the only entity that can make a particular representation or class o fr epresentations, or combinations thereof Various entities within the infrastructure may wish to make certain risk or security related representations, either publicly or to others within the system. System 1001 may provide an ability to make such representations and to charge or be charged for them on a system wide 3005 or peer to peer basis 3006. 36 WO 2005/124622 PCT/US2004/029364 Similarly, key escrow type mechanisms may be deployed to hide information, though not necessarily identity information, at carrying entity 3001. Identity or other information may be encrypted such that, for example, a government entity 2001 may decrypt to determine its original form. Key escrow technology developed in the area of cryptography and data security includes threshold schemes, secret sharing and other techniques. Central node 1001 may establish the rules, processes and mechanisms to enforce escrowing where necessary. In some cases, entities in the system may be required to prove electronically, such as through cryptographic and data security proof mechanisms, that the entity operated the escrowing in a proper manner. Alternatively, pseudonyms may be used to secure certain information. Entities querying the system may require hiding of the query request. For instance, law enforcement personnel working in a global system may want to keep queries confidential. The use of private information retrieval techniques may be used to hide record queries. In addition, the entity making requests may be hidden through the use of protective techniques, such as onion routing, known in the field of cryptography and data security, for example. Aggregation nodes 1005 may be decision nodes, namely points at which a risk related decision in regard to a document must be made. Decision nodes may be an entity within system 1000 that may make a decision whether to allow a transaction to proceed in a customary fashion, or how to proceed and at what cost, in regard to risk related information received from system 1000, system participants or others. For example, carrying entity 3001 may decide whether to agree to carry a particular container, or the conditions under which it will agree to carry such a container. Decision nodes may include, among others, central node 1001, the outbound logistics provider, the importer, the consignee, the customs house broker, the insurer, the financier, a government agency or a terminal, by way of non-limiting example only. Referring now to Figure 13, there is shown the risk transfer, information aggregation and trust infrastructure of a system in accordance with Figure 10, according to an aspect of the present invention. Decision node may decide whether to carry a container or set conditions for carriage b ased upon risk r elated information o r liability bearing representations received. Central node 1001 may decide to nominate 4001, 4002 the container for certain types of insurance coverage based on information and liability bearing representations received. Similarly, an underwriting entity may decide whether 37 WO 2005/124622 PCT/US2004/029364 to offer coverage to a particular container, cargo or shipment based upon aggregate information received through system 1000, or upon liability bearing representations regarding certain information states received. Which decision node decides to carry may be determined through a number of possible aspects, including region of container, insurance carrier, home port, destination port and type of cargo, by way of non-limiting example only. In making the decision, the decision node may rely either upon information it receives and analyzes and/or upon a liability bearing representation that a certain security or risk compliance state has been achieved in regard to a particular cargo, container or shipment. The analysis for a document may be based on other information about other documents, such as containers or shipments, obtained by system 1000, or by reference to facts surrounding other shipments to ensure a broad view is taken for evaluating the granular risk of a single container 4003. The failure of a representation to be true may be met with exoneration of any liability by any entity that made a decision to accept risk based upon the representation, as well as with grounds to claim back against the node generating the failed representation. System rules may also provide for certain reserves or collateral to be provided by member entities to back stop failed representations. Though decisions may be real time, "reversals" or "mitigating actions" m ay b e possible after a decision is made. That is, the decision to allow a supply chain process to proceed, such as the loading of a container onto a ship, may be made; however, due to information unknown at the time the "allow" decision is made, subsequent information which indicates that the document, or in this example, the container, represents a greater risk than previously believed, in essence, a reversal or a mitigation, may be performed. If, as in the present example, the shipment is in-transit, a reversal may not be possible or practical and other mitigating actions may be initiated, such as unloading at the nearest port or examination while on board by crew or other risk and security experts. By way of example, after loading a container when a ship is in transit, it is determined through newly developed intelligence that the entity that loaded the container is related to a terrorist organization. It may then be necessary, despite any previous "allow" or "load" decision, to re-evaluate the past decisions, and make new ones based on the current perception of the risk and initiate reversing or mitigation actions based on the new data. Compliance with security policy as implemented within the system rules may make a c ontainer a ssociated w ith o r a s a d ocument eligible for nomination for certain 38 WO 2005/124622 PCT/US2004/029364 insurance coverage. For example, rule compliance may be a pre-condition to obtaining liability insurance for the container, or may be a pre-condition for having a terrorism or nuclear exclusion waived or otherwise having such coverage provided. Data passed between system nodes may be protected against interception or tampering, and authorized persons or systems at the nodes should be subject to appropriate levels of authentication. System 1000 may support the use of computer security techniques such as, but not limited to, encryption, access control mechanisms, error correction protocols, etc. to achieve these objects, by way of non-limiting example only. According to an aspect of the present invention, each p erson, d evice or process within the invention may be issued cryptographic tokens or other materials after appropriate identification 4003 of the person, device or process. This token or material, when correctly presented, may authenticate 4003 the person, device or process. Cryptographic techniques, known to those possessing an ordinary skill in the p ertinent arts, may be used to assure that data is not altered without authorization or otherwise corrupted in a non-evident manner. When authentication technology involves the use of public key cryptography techniques, public keys may be kept in a central directory and not disseminated in certificates, and the public key linked to permissions and other relevant data may be held in a directory. Referring now to Figure 14, there is shown a specific embodiment of the system of F igure 1 0. S ystem 5 000 m ay include a c entral n ode 5 001 that disseminates policy regarding security risk associated with documents representative of cargo in international trade, and a set of system rules to govern the behavior of all actors within system 5000. Central node 5001 may act as an information cut-out between commercial entities to protect competitive information. The ability for any node to act as the information cut out for other nodes may be defined in the system rules. A set of nodes, including central node 5001, may receive representations regarding a security state, and may be authorized on behalf of the representing party to pass the representation on transitively to a relying party. This provides the ability to set policy among nodes, either on a system wide, bilateral or multilateral basis, to address acceptable counterparty risks in accepting or acting upon values for documents. Mechanisms may be present to permit systems to communicate on a peer to peer basis to demand or request payment for, or make payment for, provision of certain infonnation, and which may be used as an information pricing mechanism. An authentication and security infrastructure to prevent and detect improper 39 WO 2005/124622 PCT/US2004/029364 persons, entities, devices and processes from participating within the system, and to assure data integrity, may be administered by or for the central node 5001. A carrying entity 5002 may develop routes and status and may provide facilities to facilitate shipment. Carrying entity 5002 may provide route information for the 24 hour rule filing and may be a first party facility security status and may provide container monitoring while in transit. A tracking entity 5003 may be the entity responsible for receiving data about a document, such as cargo, once the cargo leaves the freight station. Tracking entity 5003 may provide in transit data collected through special screening and may provide data regarding the contents, in the form of values, of an item associated with a document, such as a container, and such content information may include the readouts of interior sensors, position o f cargo, trip duration and mileage traveled, by way of non-limiting example only. Tracking entity 5003 may include information about intermediate destinations. Additionally, or alternatively, other information may be monitored through the use of the present invention, at least by virtue of the values within documents tracked by the system 1000 of the present invention. For example, transactions may be security-scored by independent transaction part, or by overall transaction. Scoring may include, for example, purchase ordering, invoicing, or container storage, for example. Scoring may likewise be directed to, for example, any business processes, including manual, electronic, or a blend of both, and scoring may be for all, or select portions, of any document or flow. Reporting may be available for any division, or for the entirety, of the application of the present invention. Reporting may be electronic, or paper, for example. One skilled in the art might implement the present invention by using readily available hardware and software techniques, in accordance with the teachings set forth herein and the references referred to herein and incorporated into this disclosure. Further, any of a variety of computing aspects, languages, or scripts, including XML, may be incorporated into the present invention. Those of ordinary skill in the art may recognize that many modifications and variations of the present invention may be implemented without departing from the spirit or scope of the invention. Thus, it is intended that the present invention covers the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents. 40

Claims (53)

1. A system for risk management associated with at least one business process, said system comprising: a first node forming at least a portion of a plurality of communicatively connected nodes for collecting at least one risk related data value associated with at least one document; a second node of the plurality of communicatively connected nodes communicatively connected to said first node that receives said at least one risk related data value and, in accordance with said at least one risk related value, evaluates said at least one document associated with said at least one risk related value against at least one of a plurality of risk categories; wherein said second node implements said at least one risk category pursuant to at least one risk policy approved by a central one of the plurality of communicatively connected nodes for the at least one business process; and wherein said second node determines whether a risk of said at least one document exists pursuant to a rating score for said at least one document according to said at least one risk category.

2. The system of claim 1, wherein the risk is associated with infrastructure.

3. The system of claim 1, wherein said at least one document is a cargo container.

4. The system of claim 1, wherein said evaluating by said second node comprises a required intervening by at least one member of a group specified in said at least one risk policy.

5. The system of claim 4, wherein said implementing comprises at least one notification to the at least one member.

6. The system of claim 1, wherein said determination allows said at least one document to enter the business process. 41 WO 2005/124622 PCT/US2004/029364

7. The system of claim 1, wherein said at least one document comprises a survey.

8. The system of claim 1, wherein said at least one document comprises a superset of a second plurality of documents.

9. The system of claim 1, wherein said at least one risk policy is hierarchical.

10. The system of claim 1, wherein said at least one risk policy has at least one qualification associated therewith.

11. The system of claim 10, wherein said at least one qualification is hierarchical.

12. The system of claim 1, wherein said at least one document describes at least one asset in the at least one business process.

13. The system of claim 12, wherein said evaluation by said second node comprises evaluating for at least one of the group consisting of controls on physical security, controls on personnel security, controls on data systems, historical controls, insurance, actions against the asset, contractual controls, vendor controls, record keeping, and auditing controls.

14. The system of claim 13, wherein said auditing controls include authorization.

15. The system of claim 13, wherein said auditing controls include denial.

16. The system of claim 13, wherein said auditing controls include physical custody.

17. The system of claim 1, wherein said determination by said second node disallows use of said at least one document in the at least one business process.

18. The system of claim 1, wherein said second node sets at least one of said at least one risk policy for the at least one business process. 42 WO 2005/124622 PCT/US2004/029364

19. The system of claim 1, wherein said at least one policy at least partially governs interaction of at least one node of said plurality of communicatively connected nodes.

20. The system of claim 1, wherein said at least one policy at least partially governs how said second node determines risk.

21. The system of claim 1, wherein the transfer of data is at least partially governed by at least one contractual relationship.

22. The system of claim 1, wherein the transfer of data is at least partially governed by at least one set of enforceable rules.

23. The system of claim 1, wherein the transfer of data is at least partially governed by at least one set of enforceable standards.

24. The system of claim 1, further comprising security suitable for authentication of entities.

25. The system of claim 1, further comprising security suitable for assuring the integrity of data.

26. The system of claim 1, wherein said determination by said second node indicates acceptable risk associated with a document.

27. The system of claim 26, wherein said determination by said second node is a precursor to obtaining insurance or financing for the goods associated with the document.

28. The system of claim 1, wherein said plurality of communicatively connected nodes comprises a computerized network.

29. A method for managing risk associated with at least one business process, said method comprising the steps of: 43 WO 2005/124622 PCT/US2004/029364 collecting at least one risk related data value associated with at least one document; evaluating said at least one document associated with said at least one risk related data value against at least one of a plurality of risk categories; implementing said at least one risk category pursuant to at least one risk policy approved by a central node of a plurality of communicatively connected nodes for the at least one business process; and determining whether a risk of said at least one document exists pursuant to a rating score for said at least one document according to said at least one risk category.

30. The method of claim 29, further comprising the step of qualifying at least one of said at least one document pursuant to an approval rating of said at least one document in at least one risk category.

31. The method of claim 29, further comprising the step of disqualifying at least one of said at least one document pursuant to a disapproval rating of said at least one document in at least one risk category.

32. The method of claim 29, wherein the risk is associated with infrastructure.

33. The method of claim 29, wherein said at least one document is a cargo container.

34. The method of claim 29, wherein said evaluating comprises the step of requiring intervening by at least one member of a group specified in said at least one risk policy.

35. The method of claim 34, wherein said implementing comprises the step of notifying said at least one member.

36. The method of claim 29, wherein said determining allows said at least one document to enter the business process.

37. The method of claim 29, wherein said at least one document comprises a survey. 44 WO 2005/124622 PCT/US2004/029364

38. The method of claim 29, wherein said at least one document comprises a superset of a second plurality of documents.

39. The method of claim 29, wherein said at least one risk policy may be hierarchical.

40. The method of claim 10, wherein said qualifying may be hierarchical.

41. The method of claim 29, wherein said at least one document describes at least one asset in the at least one business process.

42. The method of claim 41, wherein said evaluating comprises evaluating for at least one of the group consisting of controls on physical security, controls on personnel security, controls on data systems, historical controls, insurance, actions against the asset, contractual controls, vendor controls, record keeping, and auditing controls.

43. The method of claim 42, wherein said auditing controls include authorization.

44. The method of claim 42, wherein said auditing controls include denial.

45. The method of claim 42, wherein said auditing controls include physical custody.

46. The method of claim 29, wherein said determining disallows use of said at least one document in the at least one business process.

47. The method of claim 29, further comprising the step of setting at least one of said at least one risk policy for the at least one business process.

48. The method of claim 29, wherein said at least one policy at least partially governs interaction of at least one node of said plurality of communicatively connected nodes.

49. The method of claim 29, further comprising the step of securing authentication of at least one entity. 45 WO 2005/124622 PCT/US2004/029364

50. The method of claim 29, further comprising the step of assuring the integrity of data.

51. The method of claim 29, wherein said determining indicates acceptable risk associated with a document.

52. The method of claim 51, wherein said determining is a precursor to obtaining insurance or financing for the goods associated with the document.

53. The method of claim 29, wherein said plurality of communicatively connected nodes comprises a computerized network. 46