Enterprise Technology Programs in Financial Services

Four consultant engagements between 2011 and 2015, inside four financial institutions. They were separate programs with separate sponsors and no relationship to one another, and this page keeps them separate.

They are grouped here because they taught the same thing. In a regulated environment, nothing reaches production because someone is confident. It reaches production because the requirement was written down, the tests were planned and run, the defects were resolved and retested, a business owner confirmed the outcome, and the release was controlled. That sequence is slow in the places where being fast is dangerous.

That is the discipline the AI and automation work in this portfolio is built on. When the sending platform refuses to start a campaign because a readiness check has not completed, or when the agent governance layer denies an action because it cannot reach the capability registry, that is the same idea implemented in code: the control is structural, not a matter of anyone remembering it.

Business Analyst, Consultant — Loan IQ, Back-Office Technology Delivery and Reference Data · New York, NY · January 2011 — July 2012

Business context

Loan servicing and back-office processing are unforgiving. The processing has to be accurate, the data behind it has to be right, the controls have to hold, and operations and technology have to agree on what a change is supposed to do before it is made. A system improvement that is technically correct and operationally wrong is still a failure — and it surfaces in a place where money moves.

What I did

I supported Loan IQ and related back-office functions across the loan-servicing lifecycle, on initiatives to improve servicing processes, strengthen operational controls and deliver system enhancements.

• Requirements and process mapping. Gathered requirements from operations and technology stakeholders, mapped the business processes and the data flows between systems, and documented new and updated processes with the process owners who had to live with them.
• Testing coordination. Created test cases from the documented requirements, coordinated system integration testing, and executed or coordinated the testing itself.
• Defect management. Managed defects through to resolution with the technology teams, then coordinated retesting against project deadlines rather than treating a delivered fix as a closed defect.
• User acceptance testing. Coordinated UAT with the operations staff who ran the process, so acceptance came from the people the change affected.
• Business validation. Confirmed the intended operational outcome actually occurred — not only that the software behaved as specified. Those are different tests and only one of them is the point.
• Reference data and settlement. Supported reference-data and settlement-related systems, including a migration of settlement instruction and holdings data from a third-party source into a new internal static-data system, and acted as subject-matter expert on those reference-data processes.
• Controls. Participated in quarterly audits verifying security description breaks, and monthly statement reviews.

Why this engagement matters to a product role

It is where I learned that the artifact is the deliverable. A requirement nobody wrote down is a conversation. A test case traced to a process step is evidence. A defect closed without a retest is a defect. Product and program work in any industry runs on exactly those distinctions.

The sequence below is the one I ran on the Credit Suisse delivery and, with different names, on the Morgan Stanley quarterly enhancement cycles. Every step has an entry condition; the value is in refusing to skip one.

The two artifacts behind this flow — the UAT plan and the defect status report — are published on the artifacts page as representative reconstructions: the structure and the rules, without the employer's data.

Business Analyst, Moody's Information Technology (Consultant) · New York, NY · July 2014 — April 2015

Discovery phase of a large IT initiative with an approximately $45 million program budget, against an unusual niche business model — which mattered, because none of the standard patterns fit it cleanly.

• Problem definition. Captured the business problem statement, the current state, the desired future state and the business case, identifying the business needs and the user groups each change would affect.
• Requirements and design support. Contributed to high-level technical design: business requirements, future-state solution architecture diagrams, and documentation of stakeholder workshops and interviews.
• Use cases and user stories. Developed both, to communicate requirements to senior managers and technology teams in the form each audience could act on.
• Roadmaps and sequencing. Coordinated high-level and detailed roadmaps with IT vendors and internal divisions, identifying program risks and recommending responses that kept projects in scope.
• Vendor evaluation. Built a scorecard applied across all proposals to support procurement, and recommended vendors that fit the program's constraints.
• Cost estimation. Estimated cost and sequencing using parametric estimation (QSM SLIM), t-shirt sizing and bottom-up estimation, against defined IT delivery performance targets.
• Steering committee reporting. Prepared material for senior management and the bi-weekly steering committee, covering alignment with the firm's target operating model, status and risks.

This is the closest thing in my background to a technical program management role at scale: multiple vendors, multiple internal divisions, a dependency graph nobody held in their head, and a committee that needed a decision rather than a status report.

Business Analyst, Insights & Analytics, Wealth Management (Consultant) · New York, NY · February 2013 — July 2014

Worked with the Sales Desk on an analytics and content-distribution capability that delivered firm strategy, market color and tactical trade ideas to more than 17,000 financial advisors.

• Targeting requirements. Elicited requirements from the Sales Desk and worked with big-data developers to build queries against the enterprise database, surfacing investment ideas matched to each advisor's book of business.
• Dashboard delivery. Led a small offshore team building a Tableau dashboard for regional sales directors — business analysis, requirements, delivery coordination and UAT — then owned weekly reporting and analytical consulting for its users after rollout.
• Analysis. Extracted and analyzed data using SAS and SQL, worked large data sets in Excel, and presented findings to senior executives.
• Testing. Managed end-to-end testing for internal applications across quarterly enhancements: test plans, test cases and test scripts.
• KPI reporting. Tracked and reported operational KPIs, then set targets with management.
• Documentation. Maintained training and business-process design documentation for stakeholders.

The part that transfers most directly to product work is owning the thing after launch. Delivering the dashboard was the smaller half; the larger half was the weekly reporting and the consulting conversations that told me whether the dashboard was answering the question the sales directors actually had.

FX Exotic Trade Support (Consultant) · Jersey City, NJ · August 2012 — December 2012

Supported an FX desk trading illiquid currencies that lack market depth and trade at low volume — where an error is not absorbed by the market, it just stays wrong.

• Contributed to daily processing across confirmations, payments and investigations, and compiled daily reporting on positions, problem trades, currency valuation and pending deals.
• Identified and corrected trades booked to the wrong counterparty, non-deliverable settlement discrepancies and un-booked trades ahead of valuation, and worked with the investigations team to resolve breaks and risk items within deadline.

Short engagement, narrow scope, and the origin of an instinct that shows up throughout this portfolio: reconciliation is not administration. If two systems can disagree about what happened, one of them is going to be believed, and it will be the wrong one.

Different sponsors, different systems, one sequence:

1. Understand the process as it actually runs, not as the documentation describes it.
2. Align the stakeholders who disagree, before writing anything down.
3. Document the requirements precisely enough that an engineer and a tester read the same thing.
4. Coordinate delivery across the teams and vendors who own the parts.
5. Test thoroughly — planned, traced to the process, and executed rather than asserted.
6. Resolve defects and retest them; a delivered fix is not a closed defect.
7. Validate the business outcome, which is a different question from whether the software works.
8. Support a controlled release, with the reverse path identified first.

The mechanism changed; the sequence did not.

• The requirement written before implementation became the recovery contract written as a testable statement before any code existed.
• Business validation became the readiness gate that refuses to start a send when a precondition has not completed — and fails closed rather than warning.
• Defect closure requiring a retest became a crash-recovery test that asserts timer state rather than counts, because the count-based version passed while the behavior was wrong.
• Release readiness became feature flags that default to off, so deploying and changing behavior are separate events with separate reverse paths.
• Steering committee reporting became the invariant record: the written rule with a pointer to the evidence that proves it still holds.

There are no screenshots, documents or metrics from these engagements on this site, and there will not be. They were client production environments and client programs.

What can be verified is on the resume, and the artifacts page carries representative reconstructions of the UAT plan, the defect status report, the stakeholder map, the steering committee update and the vendor scorecard — clearly labeled as reconstructions of the artifact's structure, not as copies of employer documents.

I am happy to talk through any of this in detail in a conversation, including the parts that went badly.