Control Definition
Control Objective: Ensure outbound transaction activity within the expected bounds of normal business.
In-scope components:
- GUI
- messaging interface
- communication interface
- SWIFT and customer connector
Note: Components are mentioned as the vector for outbound transaction business, not necessarily where controls are performed. Transaction activity refers to payment instructions. Reliance on other relevant recent (business) assessment, audit or regulator answers to confirm effectiveness of the control is an option34.
Risk Drivers:
- business conducted with an unauthorised counterparty
- undetected anomalies or suspicious activity
Implementation Guidance
Control Statement:
Implement transaction detection, prevention, and validation controls to ensure outbound transaction activity within the expected bounds of normal business.
Control Context:
Implementing business controls that restrict SWIFT transactions to the fullest extent possible reduces the opportunity for the sending (outbound) and, optionally, receiving (inbound) of fraudulent transactions. These restrictions are best determined through an analysis of normal business activity. Parameters can then be set to restrict business to acceptable thresholds based on “normal” activity.
Implementation Guidelines:
The implementation guidelines are common methods to apply the relevant control. The guidelines are a helpful way to begin an assessment, but should never be considered as an "audit checklist" as each user’s implementation may vary. Therefore, in cases where some implementation guidelines elements are not present or partially covered, mitigations as well as particular environment specificities must be considered to properly assess the overall compliance adherence level (as per the suggested guidelines
or as per the alternatives).
- Implement controls that will detect, prevent, or additionally validate the flow of transactions against the expected bounds of normal business. Examples of potential measures can include any or a combination of the following four elements:
- (1) limiting traffic outside of business hours
- Note: This measure may not be applicable to some users: as business hours are organisational and business unit-specific, multiple start and finish times (business hours) may need to be supported or no specific range can be defined for systems used on a 24-hour basis. In cases of 24-hour centralised SWIFT processing, limit or monitor transactions as appropriate to support business as usual.
- Consider restricting SWIFT transaction submissions and approvals outside of normal business hours 35.
- Consider enabling active FIN sessions to business hours only (for example, using automated logical terminal sessions log out at the end of the business day).
- Suspicious messages can be blended in with legitimate traffic during business hours. Therefore, always limit or monitor transactions as appropriate, to support business as usual activities considering the next elements.
- (2) limiting traffic beyond normal business amount ranges
- Consider restricting SWIFT transactions outside of customer-defined amount limits. Such limits can be specified globally, per region, traffic or known correspondents in line with functionalities offered by the used SWIFT-related interface, application or service. Putting on-hold restricted transactions for additional/off-line validation and approval (in line with separation of duties as per control 5.1) is deemed a valid control.
- (3) performing end-of-day and (possibly) intra-day validations through any or a combination of the following
- Consider implementing a process to issue and check confirmation messages (for example, to check that the MT 900 and MT 910 confirmations match the transactions which have occurred on the accounts or through potential online queries for intra-day Nostro reconciliation).
- Consider reconciling the entity's accounting records with end-of-day statement messages (for example, MT 940 and MT 950 or through potential online queries for end-of-day Nostro reconciliation).
- Consider reconciling daily (and possibly intra-day) messages that are sent to/from the back office and to/from the SWIFT Network.
- (4) performing central checks on payments to spot potential abnormal behaviour
- Consider tracking session numbers within the messaging interface to make sure that the sequential session numbering is intact with no unexpected gaps.
- Consider monitoring uncharacteristic transactions (for example, exceptionally high amounts or cumulative amounts, unusual beneficiaries, senders, or currencies) based on self-determined criteria.
- Alternatively, independent reconciliation is undertaken with a user’s transaction data securely obtained from a secondary source (either internal or external, such as the SWIFT Daily Validation Reports or other reports from service providers) or by verifying that the transaction is genuine with the emitter or the recipient (or both).
Optional Enhancements:
- Application and operating system accounts are restricted from login attempts that occur outside of the expected role-specific operational hours.
- Implement controls to ensure inbound transaction activity within the expected bounds of normal business. • Implement controls to other sensitive transactions not limited to payments.
