Managing Operational Risk of Financial Services Processes – part 2/2
- by Sanjeev Sharma
Normal
0
false
false
false
EN-US
X-NONE
X-NONE
MicrosoftInternetExplorer4
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-qformat:yes;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Calibri","sans-serif";
mso-bidi-font-family:"Times New Roman";}
In my
earlier blog post, I had described the factors that lead to compliance
complexity of financial services processes. In this post, I will outline the business implications of the increasing
process compliance complexity and the specific role of BPM in addressing the
operational risk reduction objectives of regulatory compliance.
First,
let’s look at the business implications of increasing complexity of process
compliance for financial institutions:
· Increased time and cost of
compliance due to
duplication of effort in conforming to regulatory requirements due to process
changes driven by evolving regulatory mandates, shifting business priorities or
internal/external audit requirements
· Delays in audit reporting due to quality issues in reconciling non-standard process KPIs and
integrity concerns arising from the need to rely on multiple data sources for a
given process
Next,
let’s consider some approaches to managing the operational risk of business
processes. Financial institutions
considering reducing operational risk of their processes, generally speaking,
have two choices:
· Rip-and-replace
existing applications with new off-the shelf applications.
· Extend
capabilities of existing applications by modeling their data and process
interactions, with other applications or user-channels, outside of the
application boundary using BPM.
The
benefit of the first approach is that compliance with new regulatory
requirements would be embedded within the boundaries of these applications. However
pre-built compliance of any packaged application or custom-built application
should not be mistaken as a one-shot fix for future compliance needs. The
reason is that business needs and regulatory requirements inevitably out grow
end-to-end capabilities of even the most comprehensive packaged or custom-built
business application.
Thus,
processes that originally resided within the application will eventually spill
outside the application boundary. It is precisely at such hand-offs between
applications or between overlaying processes where vulnerabilities arise to
unknown and accidental faults that potentially result in errors and lead to
partial or total failure.
The
gist of the above argument is that processes which reside outside application
boundaries, in other words, span multiple applications constitute a latent
operational risk that spans the end-to-end value chain. For instance,
distortion of data flowing from an account-opening application to a credit-rating
system if left un-checked renders compliance with “KYC” policies void even when
the “KYC” checklist was enforced at the time of data capture by the
account-opening application.
Oracle Business Process Management is enabling financial
institutions to lower operational risk of such process ”gaps” for Financial
Services processes including “Customer On-boarding”, “Quote-to-Contract”,
“Deposit/Loan Origination”, “Trade Exceptions”, “Interest Claim Tracking” etc..
If you are faced with a similar challenge and need any guidance on the same
feel free to drop me a note.
