Individual Risk Management

According to the concept of Multilateral Security, users should be able to specify the level of security they want. They will want some form of protection for their transactions, e.g., privacy. Therefore, in order to determine individual transaction risks, users must be able to specify their security requirements. These requirements are collected in so-called user requirements profiles. Each user may define several individual user profiles, according to his transaction or situation-specific needs.

For this purpose, "Configuration of User Requirements Profiles" describes several basic approaches for the configuration of user requirements profiles. Finally, "Matching User Requirements Profiles with the Electronic Payment System Profiles" describes how matching the payment systems" profiles with users' requirement profiles ascertains the measure of risk remaining.

Configuration of User Requirements Profiles

To record the user's requirements, the characteristics of the payment systems available and possible protection goals should be represented in a clear and simple way. Typically, users are not security experts. Confronting users with the full bandwidth of the detailed characteristics would put excessive demands on them (Dix, Finlay, Abowd, & Beale, 1998). The process of configuration would take too much time and would perhaps be much too confusing. For this reason, abstract protection goals like, e.g., "establishing trust," "communicating with anonymity" and even "saving costs" for the users must be found which abstract from technical details. The abstractions of protection goals should orient themselves towards the users' (subjective) requirements.

A possibility of abstracting security requirements is shown in Abad Peiro and Steiger (1998). The authors identify so-called "Business Relationship Properties" as abstract security requirements, enabling a user to define his relationship to business or payment partners. As an example, the property "identification of the user" defines which electronic commerce participants are allowed to obtain some knowledge about the user's real identity. The authors identify at least three levels as possible values for this property: everybody, only the business partner, and nobody.

A further approach to determine abstract security criteria of users as well as some insight into individual risk perception is given in (Kiefer, 2001). In this empirical study, bank customers' security requirements for Internet transactions have been approximated. There was a detailed questionnaire which aimed at revealing users' preferences concerning electronic payment systems' security characteristics by means of statistical methods.

The gap between a simple operation of the user's security configuration oriented to subjective targets and the detailed security characteristics could possibly be closed by a layering, as it is described by Faith, Cranor and Reagle Jr. (1998) for the Privacy Preferences Project (P3P) of the World Wide Web Consortiums (W3C).

In this work, the P3P approach is modified and the following layering is proposed: in order to simplify the configuration of their requirements profiles, users:

• may predefine their requirements as a type of default configuration. They may once determine general defaults of their requirements, according to which their system should act automatically (cf., "Requirements Profile for All Situations" in Figure 2);

  
  Figure 2: Layering of User Requirements Profiles.

• may predefine their requirements with respect to different types of (payment) transactions and to different user-defined situations (Damker & Reichenbach, 1998; Reichenbach, Damker, Federrath, & Rannenberg, 1997). Types of transactions may be differentiated, e.g., on the basis of the payment recipient, the amount payable, the transaction charges or the time of value transfer. Different user-defined situations could be, for instance, the purchase of digital products with online-delivery or the purchase of material products with offline-delivery. This way users may determine special requirements for specific situations beyond the general defaults (cf., "Requirements Profile for Specific Situations" in Figure 2);

• may also adapt their requirements in a given transaction-situation beyond the specific predefined requirements for this situation ("Requirements Profile in a Concrete Situation" in Figure 2). In a concrete transaction situation it is now possible to assume the users' security requirements depending on the transaction type and the predefined settings of requirements for this type of transaction. With these suppositions, the most suitable payment system for a given transaction may be chosen. Even in this case, it is helpful for users to receive experts' suggestions for meaningful configurations.

Users express their requirements by specifying the mandatory characteristics, in other words by determining those criteria which should be fulfilled at least "to a limited degree" (greater or equal value "1", cf., Figure 3).

After defining their requirements, the users are additionally able to weigh the remaining "discretionary" criteria against each other (cf., Figure 3).

In order to define and express those weights, the preference matrix method ^[5] is applied. With the list of 79 detailed criteria compiled in Reichenbach (2001) and taking into account the hierarchy of criteria that would imply a total of 3,081 comparisons ^[6] on the lowest level and still 213 comparisons on the second level. The weighting occurs situation dependent with respect to, e.g.:

• the amount payable;

• the transaction charges;

• the kind of merchandise;

• the reputation of transaction partners; or

• the liability arrangements in the event of loss.

The resulting weights flow into the user's requirements profiles and help find the most appropriate payment system at the time of transaction.

Matching User Requirements Profiles with the Electronic Payment System Profiles

After the configuration of the user's requirements profiles they may be matched against the profiles of payment systems in the user's portfolio. For this purpose, the results of the payment systems' prioritization based on the scoring model are consulted. This procedure will be supported at run-time by a consultancy and decision support system (called "Virtual Internet Payment Assistant").

It seems clear that the demand for security varies among different transaction situations, depending on types of transactions (e.g., the value of transactions) and surroundings (e.g., the level of trust among the participants). Among the variety of payment instruments available to the user, he or she will only choose a system with a security scale at least as high as required for conducting a transaction. This minimum security scale required by the user is called the level of adoption.

It is apparent that no payment instrument currently exists which fulfills all security requirements at once and which may therefore, be equally suitable for all types of transactions with respect to their specific requirements. As a result, users might not automatically choose the payment instrument with the highest security scale as a default.

Subsequently, a payment system from the user's portfolio is proposed, which achieves the adoption level best or which would require least concession of the user in order to be eligible. For all payment systems in the user's portfolio with a security scale higher than the level of adoption, selection is straightforward.

If there is one system meeting the user's adoption level, then this system is chosen. However, if this adoption level cannot be realized, the user will be informed about:

• potential upcoming security hazards;

• the maximum security scale available at transaction time (maximization of security);

• a payment system with a security level nearest to the user's level of adoption that would require as little user's concession as possible (minimization of user's concession); and

• possible combinations with individual economic tools in order to handle remaining risks.

The result of the matching process will, at first, be a response as to whether all user requirements are met or not. Since users' security requirements themselves are weighed against each other, however, even the percentage of fulfillment as an actual measure of the security scale can be achieved. It is important to note that, because of the fact that the weighting factor is transaction specific, the security scale itself is also temporary.

^[5]Mostly used in connection with the value benefit respectively scoring method.

^[6]Based on "n*(n-1)/2".