About panel authorization
With the panel authorization method, companies can configure transaction approval based on user panels. These panels are composed of groups of users.
Financial institutions that do not need the role-driven features of panel authorization may prefer to implement an alternate approval method where the number of approvers is set either as a fixed number or as a variable number based on the transaction amount. Fixed and variable approval is configured per payment type in SAM) class of service settings.
Panels and Groups
A panel consists of one to five groups, where each member is a Universal Online Banker user representing a predefined group of users in the transaction approval process. Note these key points:
- Group names are not hierarchical. For example, Group A users do not by definition have more rights or significance than users in groups B to E.
- Multiple panels can be defined so that alternative combinations of user groups are possible.
- A group can be included multiple times on one or more panels. When this is the case, a user from the group is required for transaction approval, once for each time represented on the panel.
- A user can belong to multiple groups but can approve a single transaction only once.
One configuration possibility is to set up groups so that they reflect the various roles and responsibilities of different types of users. Panels thus can be structured so that they require a specific combination of user roles to give approval to a particular transaction.
Panel profiles
The panel authorization feature uses a set of configuration parameters called a profile. The profile defines the exact parameters that must be met to approve transactions. Companies can create two separate profiles for repetitive and non-repetitive transactions, or they can create a single profile to be used for all transactions.
The profile defines the panels to be used for various transaction amounts, called limit tiers. A profile can contain an unlimited number of tiers, each defined by a minimum and maximum transaction amount. Limit tiers can overlap, and each tier can have up to nine panels.
This diagram illustrates the relationship between the items in the panel profile:
When using the panel authorization method, only these user approval limits are observed. All other limits are not observed.
- Panel tier limits
- System-wide foreign exchange payment limits
- Approving user's daily cumulative limits
- Approval repetitive limit
- Approval non-repetitive limit
Sample approval process
This example helps clarify the panel authorization structure and approval process.
Consider three groups, defined as follows:
- Group A includes UserA1, UserA2, UserA3
- Group B includes UserB1, UserB2, UserB3
- Group C includes UserC1, UserC2, UserC3
This table describes the example profile, which includes three limit tiers and multiple panels on each tier:
| Tiers | Authorizations | ||||
|---|---|---|---|---|---|
| # | Minimum | Maximum | Panels | Groups | Comments |
| 1 | 0 | 10,000 | 1 | A | Each panel in this tier has just one group. This approval scenario is simple. A user from any of the groups (A to C) can approve the transaction, and no additional approvals are required. |
| 2 | B | ||||
| 3 | C | ||||
| 2 | 10,000 | 50,000 | 1 | A B | In the second tier, the transaction amount is greater, and the approval requirements are more stringent. Three panels can potentially fulfill the approval requirements, but in this scenario, each panel needs an approval from two different groups (that is, a representative user from each group). |
| 2 | A C | ||||
| 3 | B C | ||||
| 3 | 30,000 | 100,000 | 1 | A A | In the third tier, the amount of the transaction again increases, and as a result the panel authorization requirements increase. Again, three panels can potentially fulfill the requirements. This time, the first panel includes two users from the same group (perhaps two members of upper management). The second and third panels require three approvals each. |
| 2 | B B C | ||||
| 3 | A B C | ||||
In this example, this transaction, a payment of $25,000, is awaiting approval.
- UserB1 logs on to the system and from the Pending Payments page, clicks the link to approve this payment.
- The system determines the panel profile based on whether the transaction is repetitive or non-repetitive.
- The system determines the limit tier based on the transaction amount, which in this example is Tier 2. This consequently determines all the possible panels (and groups) that can satisfy authorization requirements.
- The system checks UserB1 for membership in any of the groups on any of Tier 2's panels. This user is a member of Group B, which is on both the first and third panels. Thus, the user's approval fulfills one authorization requirement for Group B on both of these panels.
With each approval received, the system checks to see if further approvals are needed and updates the status accordingly. In this example, both panels need one additional approval, so the status remains “Pending Approval.” If either of the panels has included just a single group, the process would end at this point, and the transaction status would change to “Approved.” Since the payment still requires another approval, we can continue with the example. An approval from a user in group A or group C is needed.
Note: The first user (group representative) to provide approval determines which panel(s) will be used. In this example, the second panel falls out of the approval process because the user is not a member of any of its groups. - UserC3 logs on to the system and sees that the payment needs approval and clicks the link to approve the payment.
- The system determines the profile, tier, panel, and group requirements based on the payment's history. Since UserC3 is a member of Group C, a group that fulfills the third panel's requirements, the user successfully approves the payment. This is the final approval needed, so the system updates the status to “Approved.”
