Let Digiqt quantify your single-person dependencies and build knowledge capture and automation that outlast the people who hold it.

Reduce the Dependency Before the Retirement

# When the Only Person Who Understands It Retires in March

Every bank has one. A system that processes something essential, has run for decades, and is genuinely understood by two people, one of whom retires next year and the other of whom is a contractor. The situation is well known internally, discussed periodically, and rarely acted on, because there is no incident, no finding, and no deadline until suddenly there is.

The legacy skills shortage banking technology institutions face is not fundamentally a recruitment problem. It is a concentration of operational dependency on individuals, and it responds to the same treatment as any other concentrated dependency: measure it, reduce it deliberately, and stop assuming the current arrangement will persist.

## Why is this a risk item rather than an HR problem?

Because the failure mode is an operational one and the mitigations are engineering ones.

Framing it as recruitment leads to a search for people with skills that are genuinely scarce, at prices that keep rising, for systems that are shrinking in number. Framing it as concentration risk leads somewhere more productive: which systems, which people, what happens on the day they are unavailable, and what would reduce that dependency regardless of whether anyone is hired. The evidence that this is a real and durable pattern is not new. The US GAO's 2019 review of federal legacy systems examined ten critical systems aged between eight and fifty-one years, specifically citing COBOL and a dwindling pool of people skilled in it, and found that only two of the ten agencies had modernisation plans containing milestones, work descriptions, and disposition strategies, while three had none at all.

Operational resilience frameworks also reach this territory, since the Basel Committee's principles for operational resilience, published 31 March 2021, take a principles-based approach covering technology failures alongside pandemics, cyber incidents, and natural disasters, and build on operational risk, governance, business continuity, and outsourcing foundations. A dependency on one person to recover a critical service is a resilience question by any reading, which is the mapping discipline described in [operational resilience and impact tolerances](https://digiqt.com/blog/operational-resilience-impact-tolerance/).

### Why does the exposure concentrate in so few people?

Because the systems stopped attracting new people long before they stopped being important.

Nobody joined the institution in the last fifteen years hoping to specialise in the batch scheduler. The people who understand it learned it when it was current, stayed, and accumulated knowledge that was never written down because they were always available to answer. Each departure removes a share of that and increases the load on those remaining, which accelerates their departure. The dynamic is self-reinforcing and it does not stabilise on its own, which is why it needs deliberate intervention rather than monitoring. The wider hiring picture is covered in the technology talent shortage playbook.

> **How many people could recover your most critical legacy system at three in the morning?**
>
> [Talk to Digiqt about quantifying single-person dependency](https://digiqt.com/contact-us/)

## How do you quantify the exposure?

Per system, count who can change it, who can operate it under pressure, and how long a replacement takes.

| Dimension | What to record | Why it matters |
|---|---|---|
| Change capability | People who can safely modify it | Determines whether it can evolve at all |
| Operational capability | People who can diagnose and recover it live | Determines what happens during an incident |
| Depth of understanding | People who know why it behaves as it does | Determines whether changes are safe |
| Availability profile | Employment type, notice period, retirement horizon | Determines how much warning you get |
| Replacement time | Realistic months to competence for a new person | Determines the size of the gap |
| Consequence of failure | What stops if the system does | Determines the priority |

Publish the resulting table to executives without softening it. A system with one person able to change it, one able to recover it, and a twelve-month replacement time is a stated risk, and stating it plainly is what unlocks investment. The pattern usually correlates with accumulated technical debt, which is the subject of [reducing technical debt in core systems](https://digiqt.com/blog/packaged-core-banking-upgrade-strategy/), and with the wider workforce exposure described in workforce skill shortages.

## What knowledge actually needs capturing?

Six kinds, of which only two are usually documented.

| Knowledge type | Typically documented? | How to capture it |
|---|---|---|
| What the system does | Partially | Behaviour extraction and characterisation tests |
| How to operate it normally | Usually | Runbooks, then automate the routine steps |
| How to recover it when it fails | Rarely, and often out of date | Rehearsed recovery with the runbook updated during the rehearsal |
| Why it behaves as it does | Almost never | Structured interview and decision records |
| Which oddities are deliberate | Almost never | Annotate the anomalies before the person leaves |
| Who to call outside the institution | Never | Named contacts at vendors, schemes, and counterparties |

The fourth and fifth rows are where the real value sits and where capture is hardest, because the knowledge is not written anywhere and its holder does not experience it as knowledge. It is simply how things are.

### Why is intent the part that never gets written down?

Because the reason was obvious at the time and nobody records the obvious.

A rounding rule that appears wrong implements a regulatory requirement from 1998. A duplicated field exists because a merged entity's data could not be reconciled. A job that runs at an odd hour does so because a counterparty's file arrives then. Each decision made sense to the person who made it, none of it is in the code, and once the person leaves it is indistinguishable from a defect. The consequence is expensive: teams "fix" deliberate behaviour and discover the reason from an incident or a complaint. Capturing intent means asking specifically about the strange parts, and the question that works is not "how does this work" but "what would someone new get wrong about this".

## How do you capture behaviour rather than descriptions?

By pinning current behaviour in executable form before anyone changes anything.

Characterisation tests capture what the system actually does rather than what it should do, which is exactly what is needed when the specification is lost. Feed controlled inputs, record outputs, and assert that they do not change. For batch systems the same approach works at file level: keep a set of representative inputs and their outputs, and compare byte for byte. The result is a safety net that lets a less experienced person make a change with confidence, which directly reduces the dependency on the expert. The mechanics are the same as those described in [core banking regression automation](https://digiqt.com/blog/core-banking-test-automation/), and the resulting harness is precisely what any subsequent migration needs, whether that is [COBOL to Java conversion](https://digiqt.com/blog/cobol-to-java-modernization/) or incremental [strangler fig extraction](https://digiqt.com/blog/strangler-fig-core-banking-migration/).

### Why are tests better documentation than documents?

Because a test that becomes untrue fails, and a document that becomes untrue does not.

Documentation decays from the moment it is written, silently, and the reader cannot tell whether they are looking at current truth or a description of 2014. An executable check is verified on every run, so its accuracy is continuously proven rather than assumed. Documents remain necessary for intent, context, and the human explanations that no test can carry, but for behaviour the executable form is strictly better and it is the form most institutions invest in least.

## What can automation genuinely replace?

Routine operational work, which is most of the volume and none of the difficulty.

| Toil category | Automation approach | Residual need for expertise |
|---|---|---|
| Scheduled manual interventions | Scripted and scheduled, with alerting | Low |
| Routine restarts and clean-ups | Automated with guardrails | Low |
| Standard recovery steps | Runbook automation triggered on defined conditions | Medium, for confirming the diagnosis |
| Health checks and reporting | Fully automated monitoring | Low |
| Access and environment requests | Self-service with entitlement checks | Low |
| Diagnosing an unfamiliar failure | Not automatable | High, and rising |
| Deciding whether to intervene at all | Not automatable | High |

Automation removes the work that consumes specialists' time without using their judgement, which is worth doing on its own terms and reduces how many specialist hours the institution needs. It does not reduce how much specialist judgement it needs, and confusing the two produces a comfortable-looking operating model that fails on its first unusual day. The delivery-side version of this argument is set out in [developer velocity inside bank security constraints](https://digiqt.com/blog/developer-velocity-regulated-banking/).

### Why can automating the routine make the rare harder?

Because routine work is how people stay familiar with the system.

If every ordinary intervention is automated, nobody touches the system until something unusual happens, at which point the person responding has neither recent practice nor context. The mitigation is deliberate: rotate people through supervised exposure, run recovery rehearsals rather than reading recovery documents, and treat incident response practice as a scheduled activity rather than an outcome of bad luck. Institutions that automate heavily and then stop practising end up with fewer, less practised responders, which is a worse position than the one they started from.

> **Has anyone actually rehearsed recovering that system, or only read the runbook?**
>
> [Talk to Digiqt about recovery rehearsal and knowledge capture](https://digiqt.com/contact-us/)

## Should modernisation be the answer?

Sometimes, but not as a response to the skills problem alone.

Replacing a system because it is hard to staff is an expensive way to solve a staffing problem, and it typically takes longer than the retirement horizon that prompted it. Modernise where there is a business case in its own right, as covered in [legacy core system modernisation](https://digiqt.com/blog/packaged-core-banking-upgrade-strategy/), and in the meantime reduce the dependency through capture and automation, which delivers value in months rather than years. Targeted extraction is often the better middle path: remove the two or three functions that generate most of the change requests, leave the stable remainder alone, and shrink the surface that needs scarce expertise. Cost pressure sometimes provides the business case independently, as discussed in [mainframe cost reduction](https://digiqt.com/blog/mainframe-mips-cost-reduction/), and restructuring overnight processing often removes a large share of the manual intervention burden, as covered in [batch window elimination](https://digiqt.com/blog/batch-window-elimination-banking/).

## What are the sourcing options, honestly?

Five, each with a real limitation worth stating.

| Option | What it gives | The limitation |
|---|---|---|
| Retain the current holders | Continuity | Deferral, not resolution, and cost rises each cycle |
| Retrain existing engineers | Institutional context plus new skills | Slow, and only works if the work is interesting enough to keep them |
| Apprenticeship or graduate pipeline | Long-term supply at reasonable cost | Requires experienced people to teach, which is the scarce resource |
| Specialist contractors | Fast capability | Knowledge leaves with them unless capture is contractual |
| Managed service or vendor | Transfers the operational load | Transfers dependency rather than removing it, and requires exit testing |

The contractor row deserves emphasis. Bringing in a specialist without a knowledge capture obligation in the engagement produces a dependency that is more expensive and less loyal than the one it replaced. Make capture a deliverable with acceptance criteria. The managed service row deserves equal care, since dependency on a supplier carries the whole third-party discipline described in [technology vendor due diligence and exit testing](https://digiqt.com/blog/vendor-due-diligence-banking-technology/).

## How do you handle a known retirement?

Treat the notice period as a capture programme with deliverables, and start before the notice.

The worst version of this is a leaving date, a handover document written in the final week, and a farewell. A workable version starts a year out: paired working on real changes, the departing expert reviewing rather than performing, capture of intent through structured interviews focused on the anomalies, characterisation tests written together, and recovery rehearsals led by the successor with the expert observing. Where the relationship allows, a part-time consultancy arrangement after departure is worth having as insurance, and it is far cheaper to negotiate before the person leaves than after.

## How should this be sequenced?

Measure, capture intent while people are still there, pin behaviour, then automate.

| Phase | Duration | Deliverable |
|---|---|---|
| Dependency mapping | 1 month | Per-system counts of change and operational capability, with horizons |
| Prioritisation | 2 weeks | Ranked by consequence times fragility, agreed with risk |
| Intent capture for the top systems | 2 to 3 months | Structured interviews, decision records, annotated anomalies |
| Characterisation testing | 3 to 4 months | Executable behaviour capture with a comparison harness |
| Runbook rewrite through rehearsal | 2 months | Recovery documents corrected by actually performing recovery |
| Operational automation | 3 to 4 months | Routine toil removed, with guardrails and alerting |
| Successor development | 6 to 12 months | Named successors with supervised real experience |
| Targeted extraction | 6 to 12 months | The highest-churn functions moved off the constrained platform |

Intent capture comes early deliberately. It is the only item on the list that becomes impossible rather than merely harder once the person has gone.

## Which metrics matter?

Capability counts per system, capture coverage, characterisation coverage, manual intervention volume, and time to competence.

Report how many people can change and how many can operate each critical system, and treat any count of one as a named risk with an owner and a date. Report knowledge capture coverage against the priority list. Report characterisation test coverage as the measure of whether change is safe for a non-expert. Track manual intervention volume as the automation measure. And measure time to competence for people joining the area, since a falling figure is the clearest evidence that capture and automation are working, and a static one means the knowledge is still in people's heads.

The retirement date is fixed and the capture window is not. What makes this tractable is accepting that the goal is not to replace the expert, but to reduce how much the institution needs one.

## Frequently Asked Questions

### Why is the legacy skills shortage a risk item rather than an HR problem?

Because it is a concentrated dependency on a small number of people for systems the institution cannot stop running, which is the same shape as any other single point of failure.

### How do you quantify the exposure?

Count, per system, how many people can change it, how many can operate it under pressure, and how long a replacement would take to become effective, then rank by consequence of failure.

### What knowledge actually needs capturing?

What the system does, why it does it that way, how to operate and recover it, what breaks and how it presents, and which apparent oddities are deliberate business rules.

### Why is intent the part that never gets written down?

Because behaviour is visible in the code while the reason for it lived in a decision made years ago by people who have left, and nobody records reasons at the time.

### Why are tests better documentation than documents?

Because a test fails when the system changes, so it cannot quietly become untrue, while a document describing the same behaviour decays silently from the day it is written.

### What can automation genuinely replace?

Repetitive operational toil such as routine restarts, scheduled interventions, and standard recovery steps. It does not replace the judgement needed when something unexpected happens.

### Why can automating the routine make the rare harder?

Because the routine work is how people build familiarity, so removing it without deliberate exposure to the system leaves nobody practised when an unusual failure occurs.

### What should be measured?

People able to change and operate each critical system, knowledge capture coverage, characterisation test coverage, manual intervention volume, and time to competence for new joiners.

## Sources

- [GAO-19-471, Information Technology: Agencies Need to Develop Modernization Plans for Critical Legacy Systems](https://www.gao.gov/products/gao-19-471)
- [BCBS, Principles for operational resilience](https://www.bis.org/bcbs/publ/d516.htm)

Legacy Skills Shortage in Banking: Automation and Knowledge Capture

Let Digiqt design nostro vostro reconciliation automation that clears the routine breaks and surfaces the ones that matter.

Match More, Investigate Less

# Automating the Match Between Your Books and Your Correspondent's

Nostro reconciliation is the work nobody wants to talk about and every operations head knows the cost of. Statements arrive, an engine matches what it can, and a team spends its days on the residue, chasing items where a reference was truncated three hops upstream or a fee was deducted without notice.

The instinct is to buy a better matching engine. Matching rates certainly improve with better tooling, but the ceiling is set by the data arriving, and the cost is dominated by what happens to unmatched items rather than by the match itself. Nostro vostro reconciliation automation that changes the economics has to work on all three: match rate, upstream data quality, and the exception workflow.

## What makes correspondent account reconciliation hard?

Two independent records of the same flows, produced by different systems, with references that rarely survive intact.

A nostro is your account with another bank and a vostro is their account with you, and in both directions you hold a ledger while they issue a statement. Neither is wrong, they simply differ in timing, in fee treatment, and in how much of the original reference data survived. The Basel and CPMI work on correspondent banking documents a long-running decline in active correspondents and corridors, which matters here because a shrinking network concentrates volume onto fewer relationships and makes each one's data quality more consequential.

### What actually causes breaks?

Timing, fees, FX, destroyed references, and netted or partial settlement, with genuine errors a small minority.

| Break cause | Typical share | Right treatment |
|---|---|---|
| Timing difference across value dates or cut-offs | Large | Auto-match with a tolerance window, no human involvement |
| Fees or charges deducted at source | Large | Rule-based matching on amount minus expected fee |
| FX rounding and conversion differences | Medium | Tolerance thresholds by currency pair |
| Truncated or missing references | Medium | Multi-attribute matching, then upstream fix |
| Netted or partial settlement | Medium | Group matching across many statement lines |
| Duplicate postings | Small | Deterministic detection and immediate alert |
| Genuine unrecorded movement | Small | Immediate escalation, never queued by date |

The distribution matters because it tells you where to invest. If most breaks are timing and fees, they should never reach a human, and an engine that leaves them unmatched is generating labour rather than value.

### Why does the cost sit in investigation rather than matching?

Because an unmatched item consumes an analyst, a correspondent enquiry, and days of elapsed time regardless of its value.

The marginal cost of a matched item is nearly zero and the marginal cost of an unmatched item is an investigation with a wait attached, so match rate improvements compound. That is also why a small increase in the auto-match rate can remove a disproportionate share of the operating cost, and why measuring only match percentage misses the point: measure the labour and elapsed time behind the residue too, in the same way the [quarterly close analysis](https://digiqt.com/blog/financial-close-automation-banking/) shows where cycle time actually accumulates.

> **Is your reconciliation team spending its days on timing differences and fee deductions?**
>
> [Talk to Digiqt about a reconciliation automation assessment](https://digiqt.com/contact-us/)

## How should the matching engine be designed?

As tiered matching with tolerances and confidence scoring, producing auto-matches, suggestions, and exceptions.

Run cheap deterministic passes first and reserve expensive candidate generation for what survives. Each tier should be independently configurable and independently measurable, so you can see which rule earns its place.

### Which matching tiers make sense?

Exact reference, then multi-attribute with tolerances, then group matching, then scored candidate suggestion.

Start with unique reference matching, which should clear a large share instantly where references survive. Then match on amount, currency, value date, and counterparty within configured tolerances, with fee-adjusted amount variants. Then attempt group matching for netted and partial settlements. Only what remains goes to scored candidate generation, where the engine proposes ranked possibilities for a human to confirm. Keep every tier's decision recorded on the item, because when someone asks why two items matched, the answer must be a rule and its inputs rather than a black box.

### How do you handle one-to-many and many-to-many matches?

Model matches as groups with a shared identifier, never as pairs.

A single outbound payment can appear as several statement lines, several payments can settle as one netted credit, and a partial settlement can produce a residual that matches later. An engine built on pair relationships cannot express any of that, and teams work around it with manual journals that destroy the audit trail. Design the match as a set of items on both sides with a group identifier, a status, and a residual, and allow a group to be reopened when a late item arrives. This is the same structural problem described in reconciling data conflicts across functions, where the mismatch is in the shape of the relationship rather than in the numbers.

### Why does a confidence threshold beat a binary decision?

Because it separates auto-match, one-click confirmation, and genuine investigation.

Set two thresholds. Above the upper one, match automatically and record the rule. Between the two, present the item with its best candidates for a single-click confirmation, which takes an analyst seconds rather than minutes. Below the lower one, route to investigation. Then tune the thresholds using outcome data: if confirmations are almost always accepted, the upper threshold is too high and you are paying humans to agree with the engine. That tuning loop is where most of the achievable improvement sits after the initial build.

## How do you fix the data problems upstream?

By treating every truncated reference as a defect with a traceable origin rather than as a fact of life.

Some data loss is imposed by counterparties and formats, and some is self-inflicted. The CPMI has documented how legacy formats truncated data and how translation between standards loses information, which is a large part of why harmonised ISO 20022 data requirements exist. Internally, the question is whether your own estate preserves structured references end to end or flattens them at some hop. Instrument that: sample items that arrived unmatched, trace the reference backwards, and identify the specific system that dropped it. Fixing one internal truncation point usually improves match rates more than any engine change, and it is exactly the benefit that [modernised messaging and connectivity](https://digiqt.com/blog/swift-gpi-api-connectivity/) is supposed to deliver.

### What makes statements themselves unreliable?

Missing days, restatements, inconsistent fee presentation, and varying granularity between correspondents.

Track statement arrival as a monitored obligation per account, with alerting when an expected statement does not arrive, because a missing statement silently stalls reconciliation and nobody notices until a month end. Handle restatements as new versions rather than replacements. Record each correspondent's fee presentation convention as configuration so the engine can apply the right adjustment rather than guessing. And measure data quality per correspondent, because that gives your relationship managers something concrete to raise, and the differences between correspondents are usually large enough to act on.

> **Would you know today if a correspondent statement had not arrived?**
>
> [Talk to Digiqt about statement monitoring and data quality scoring](https://digiqt.com/contact-us/)

## How should exceptions be worked?

By category, prioritised on value and age, with a defined action and target clearance per category.

| Break category | Priority | Action |
|---|---|---|
| Suspected unrecorded cash movement | Immediate | Escalate to finance and treasury, investigate same day |
| Duplicate posting | Immediate | Reverse after verification, alert originating system owner |
| High value, unexplained | High | Assign named owner, contact correspondent, daily review |
| Aged over threshold | High | Escalation ladder with management visibility |
| Fee or FX difference within pattern | Low | Auto-resolve by rule, sample for assurance |
| Low value, aged | Low | Bulk write-off under approved policy with reporting |

Two disciplines make this work. First, every item has a named owner and a target clearance time, since an unowned queue ages indefinitely. Second, write-off policy must exist and be applied, because carrying thousands of trivial aged items obscures the ones that matter and turns the report into noise. Both are the operational equivalent of the controls described in pledged asset reconciliation, where ageing and ownership determine whether breaks get resolved or accumulate.

## How does reconciliation quality affect liquidity?

Unreconciled balances are unavailable for funding, so poor matching is a liquidity cost as well as an operating cost.

Cash you cannot explain is cash you cannot use with confidence, which means treasury funds around it and the bank carries a larger buffer than necessary. Unreconciled nostro positions also distort the intraday and end-of-day view feeding the [real-time treasury platform](https://digiqt.com/blog/real-time-treasury-platform/), and trapped balances in low-activity correspondent accounts are a recurring finding in corridor reviews. Report the value and ageing of unreconciled balances per account to treasury, not just to operations, because that reframes reconciliation from a back-office metric into a funding one and usually unlocks the investment case.

## Where should machine learning be used?

For candidate generation and ranking, with deterministic rules retaining the auto-match decision.

Learned models are good at proposing which statement line probably corresponds to which payment when references are absent, using patterns in amounts, counterparties, timing, and prior analyst decisions. Let them suggest and rank, and let analyst confirmations feed back as training signal. Keep the automatic match decision on explainable rules, because an unexplained automatic match is difficult to defend in an audit and impossible to debug when it is wrong. Over time, patterns the model finds reliably can be promoted into explicit rules, which is a better path than gradually handing the decision to a model nobody can interrogate.

## How should delivery be phased?

Measure the current break profile first, then tiers and tolerances, then exception workflow, then upstream fixes.

| Phase | Duration | Deliverable |
|---|---|---|
| Break profile analysis | 1 month | Categorised current breaks by cause, value, and labour cost |
| Deterministic tiers and tolerances | 2 to 3 months | Reference, multi-attribute, and fee-adjusted matching with recorded rules |
| Group matching | 1 to 2 months | One-to-many and many-to-many with residual handling |
| Exception workflow | 2 months | Ownership, ageing, escalation, write-off policy, correspondent enquiry tracking |
| Statement monitoring and data scoring | 1 to 2 months | Arrival alerting, per-correspondent quality scores |
| Suggestion model and tuning | 2 to 3 months | Candidate ranking, threshold tuning from outcomes |
| Upstream reference fixes | Ongoing | Truncation points identified and removed system by system |

The first phase is the one teams skip and the one that determines everything else. Without a measured break profile, you cannot tell whether a matching engine or a data fix is the better investment, and most banks guess wrong.

## Which metrics prove the engine works?

Auto-match rate, touches per break, break ageing, unreconciled value, and match reversals.

Report auto-match rate by account and by correspondent rather than as a single figure, since the average hides the relationships causing the work. Measure touches per break and elapsed time to clearance, because those capture the actual cost. Track the ageing profile of open breaks and drive the tail down. Report unreconciled value to treasury as a funding item. And watch match reversals, meaning matches later found to be wrong, since a rising reversal rate means your thresholds or tolerances have drifted too loose and the auto-match rate is flattering you.

Reconciliation will never be interesting, and it will always be one of the clearest places in a bank where better data upstream shows up as fewer people downstream. The engines that succeed are the ones tuned against a measured break profile, with an exception process that owns and ages every item, and an ongoing campaign to stop destroying the references in the first place.

## Frequently Asked Questions

### What is the difference between a nostro and a vostro account?

A nostro is your account held with another bank, a vostro is their account held with you. Both need reconciling against statements, and each direction has its own failure patterns.

### What causes most reconciliation breaks?

Timing differences and destroyed references. Genuine errors are a small minority, which is why an engine that only matches on exact references leaves most items unmatched.

### Why does a confidence score beat a binary match?

Because it lets you auto-match high-confidence pairs, route medium confidence for one-click confirmation, and reserve investigation for genuinely ambiguous items.

### How do you handle one payment matching several statement lines?

Model matches as groups rather than pairs. Any engine restricted to one-to-one relationships will fail on netted settlements, partial payments, and fee deductions.

### Should machine learning be used for matching?

Yes, for suggesting candidates and ranking them, with deterministic rules holding the auto-match decision. Suggestions accelerate humans, and unexplained automatic matches create audit problems.

### Why do payment references get destroyed?

Legacy formats truncate fields and translation between standards loses data, so a reference that left your system intact can arrive unusable at the other end.

### How should breaks be prioritised?

By value at risk and age, with any item that suggests unrecorded cash movement escalated immediately rather than queued by date received.

### What is the real cost of poor reconciliation?

Investigation labour plus trapped cash. Unreconciled balances sit unavailable for funding, so bad matching is a liquidity cost as well as an operations cost.

## Sources

- [CPMI, Payment system and correspondent banking statistics](https://www.bis.org/cpmi/paysysinfo.htm)
- [CPMI, Harmonised ISO 20022 data requirements for enhancing cross-border payments](https://www.bis.org/cpmi/publ/d230.htm)
- [CPMI Brief 11, The future of financial messaging: navigating the ISO 20022 migration journey](https://www.bis.org/cpmi/publ/brief11.htm)

Posts tagged with#Operations

Legacy Skills Shortage in Banking: Automation and Knowledge Capture

Nostro Vostro Reconciliation Automation With Matching Engines

Our Offices