ServiceNow Request Fulfilment and Service Catalog for Financial Services

Request fulfilment in financial services has to produce records that hold up to regulator and auditor review: who requested what, who approved it, when, and under which policy. The design work is approval routing that enforces segregation of duties, audit trails that cannot be edited after submission, and separate catalog experiences for each function.

Request Fulfilment and Compliance in Financial Services

Financial services organisations face external regulatory scrutiny of request processes. Audit teams, regulators, and third-party assessors review who requested what, who approved it, when approvals occurred, and whether requests followed documented policies. Request Fulfilment must produce audit-ready records that survive multi-year examination. This means immutable audit logs, approval chains that are clearly documented, and request records that cannot be modified after submission—even by administrators.

Financial services catalogs typically separate trading operations, compliance functions, risk management, and back-office support. Trading floor requests (terminal access, market data subscriptions, execution permissions) have different urgency and approval criteria than compliance requests (policy updates, training certifications, access reviews). A single service catalog design cannot accommodate both without creating confusion or security gaps. Leading organisations maintain separate portal experiences for each function group.

Segregation of Duties and Approval Architecture

Regulatory guidance (Basel III, Dodd-Frank, MiFID II, depending on jurisdiction) requires segregation of duties in financial systems. A single person should not request access, approve the request, and subsequently use the approved access without additional oversight. Request Fulfilment enforces this through approval workflows that require multiple approvers from different departments. A trading desk member requesting privileged database access should have approval from both their manager and the database administrator—two independent roles.

Implementation of segregation rules extends beyond simple approval chains. An operations manager approving a cash transfer request should not also approve the settlement instruction for the same transaction. A compliance officer designing a new surveillance rule should not later certify that the rule is operating correctly. Request Fulfilment configuration must map these segregation rules into approval routing, often using a decision table approach where request attributes (request type, amount, requestor role) determine the required approvals.

Financial services organisations implement additional controls by assigning request approvals to shared mailboxes or approval groups rather than individuals. This prevents single-person approval bottlenecks and ensures that knowledge is distributed across the team. However, shared mailbox approvals must still maintain clear audit trails showing which individual team member took the approval action—a shared mailbox approval alone does not satisfy audit requirements.

Audit Trail and Records Retention Requirements

Financial services Request Fulfilment configuration must ensure that audit trails survive archival and satisfy retention policies. Request records and approval chains remain readable and verifiable even after 7+ years (depending on local requirements). This requires careful consideration of how data is exported, archived, and made available during audits. Many organisations maintain request records in both active systems and immutable external archives to satisfy retention policies while keeping active systems responsive.

Approval chain modifications require special handling. If an approval workflow must be changed (a role no longer exists, approval authority changes), historical requests must remain linked to the workflow rules that were in effect when the request was created. Retroactively changing approval chains corrupts audit history. Effective implementations version workflow definitions, attach request records to the version that approved them, and maintain historical versions indefinitely for audit purposes.

Request Fulfilment systems in financial services must provide audit query capabilities that satisfy examiner needs. Auditors typically need to retrieve all requests approved by a specific person, all requests of a specific type over a date range, all requests for a specific system or data set, or all requests rejected and the reasons for rejection. The system should support these queries without requiring database access or manual log file parsing—audit teams should never need technical skills to answer audit questions.

Financial Compliance and Change Control Integration

Financial services organisations often implement Request Fulfilment as the entry point for change control processes. Every configuration change to production systems, every database schema modification, every security patch deployment should flow through the request system. This provides audit evidence that changes were approved, tested, and released following documented procedures. Change advisory board (CAB) review is invoked for high-risk changes, creating a clear approval trail that satisfies external audit requirements.

Pricing and product approval requests follow similar audit-ready workflows. A new product requires risk approval, compliance approval, and trading desk approval before launch. Pricing changes require approval from pricing management and risk oversight. Request Fulfilment tracks these approvals and creates permanent records that show the product was launched only after required approvals were in place. When a product performs poorly or creates unexpected losses, the audit trail shows whether proper approval gates were followed.

Implementation Checklist for Financial Services

• Audit logging configured to capture request submitter, all approvers, timestamps, and approval/rejection decisions; logs are immutable and non-modifiable even by administrators
• Request records cannot be edited after submission; modification requires creation of a new request with documented justification
• Approval workflows enforce segregation of duties rules specific to your institution (manager approval separate from functional owner approval, trading approval separate from risk approval)
• Request data is regularly exported to external archive systems with checksums and digital signatures for audit trail integrity verification
• Approval groups are used for most workflows rather than individual approvers; group membership changes are tracked and historical versions maintained
• Request queries and reporting are available to internal audit, compliance, and examiner access without requiring database-level access
• Change control requests are mandatory for all production system modifications; request records provide evidence of approval and testing
• Request records older than archival threshold are exported and deleted from active system; archived records remain accessible via archive query interface

Pitfalls Specific to Financial Services Implementation

Financial services organisations frequently implement approval workflows that are technically correct but operationally broken. An investment committee that meets quarterly creates bottlenecks for requests requiring investment approval—weeks of delay waiting for the next meeting. Effective implementations use proxy approvers for scheduled absences and escalation paths for urgent requests, maintaining audit evidence that escalation was justified and subsequent approvals were obtained.

Another common mistake is implementing Request Fulfilment without connecting it to wider change management and system provisioning. Requests are approved but nobody actually implements the approved change, or requests are implemented without approval. Leading organisations integrate Request Fulfilment with provisioning systems (identity access management, database administration, application deployment) so that approval transitions directly to implementation without manual handoff steps.

Retention policy violations occur when organisations delete requests to clean up active systems without verifying that archived copies exist. Always verify that requests have been successfully archived before deleting from active systems. Periodically validate archive integrity by attempting to retrieve historical requests and confirming that retrieved records match what was originally approved.

Building Audit-Ready Workflows

Financial services implementations succeed when they treat Request Fulfilment as an audit evidence system first and an operational convenience tool second. Design workflows that produce clear audit trails, approval records that are unambiguous and tamper-evident, and request data that accurately reflects decisions as they were made. Regular audit testing—actually simulating examiner queries and retrieving records—catches configuration gaps before external audits discover them.

Approvals that move at the speed of the business

In a financial firm the approval chain is where requests stall. One approver on leave, a committee that sits monthly, or a delegation nobody set up will hold a request for days. The requester can then turn to email, which bypasses the record. The design goal is an approval route that is both segregated and resilient: nobody approves a request they raised, and no request waits on one absent individual.

A working sequence for approval routes

1. Confirm which approvals are segregated by role, and write down the reason each one exists.
2. Route approvals to groups where the work is shared, and to individuals only where the decision is personal.
3. Set delegation rules for planned absence, and make each delegation expire rather than running indefinitely.
4. Attach a task-level service target to each approval, so a stalled approval is visible to the manager who owns it.
5. Test a rejected request, a timed-out request and a delegated request, and confirm the record shows who acted in each case.
6. Check monthly for requests raised outside the catalog that describe the same work.

Keeping requests inside the catalog

Email requests are a symptom, not the cause. If the catalog route is slower than email, people may keep using email. Compare the time each route takes for the most common requests, and fix the catalog route first. Any request that arrives by email and is actioned should also be entered in the record afterward, with a note that it arrived by that route, so the gap stays visible to the owner.

Checklist for an approval route

• Segregation rules are written, with the reason for each.
• Group routing is used wherever the work is shared.
• Delegations expire on a set date.
• Each approval has a service target visible to its manager.
• Rejection, timeout and delegation have each been tested.

Questions about approval design

Can an approver approve a request raised on behalf of their team?

Only if the segregation rules allow it for that request type. Where the requester and approver are in the same chain of command, the second approver should come from outside it, and the record should show both.

Should a rejected request be resubmitted or raised again?

Resubmit it when the rejection was a fixable error in the request, so the history stays with one record. Raise a new request when the requester has changed what they are asking for, because the earlier decision should remain untouched.

How should approval timeouts be handled across a holiday period?

Set the timeout to route the approval to a named deputy group rather than letting it lapse. Check the deputy list before the holiday, because a deputy who has also left the team can leave the same stall in place.

Does this route replace the change process?

No. Standard requests for access and equipment can run through the catalog. Changes to production systems follow the change process, which has its own risk assessment and approval rules. The two should link to each other, not merge.