SUNANDO ROY – On Banking, Finance and Society

From transaction recording to active surveillance

A related-party transaction register records dealings between a financial institution and its directors, controllers, senior managers, group companies, close family members and other connected persons. A red-flag register goes a step further: it identifies transactions or patterns that may indicate preferential treatment, conflicts of interest, concealment, regulatory circumvention or misuse of institutional resources.

Related-party transactions are not automatically improper. Many are commercially necessary, particularly in financial groups that share technology, premises, treasury services, employees or operating infrastructure. The risk arises when the relationship influences the institution’s pricing, credit decision, procurement process, valuation, approval route or willingness to assume risk.

The G20/OECD/BIS/ World Bank  Principles recognise that RPTs are not inherently objectionable, but their conflicts must be addressed through proper monitoring, disclosure and approval. They also call for a framework that clearly flags such transactions and protects the company and its shareholders.For banks and other financial institutions, the objective is broader than shareholder protection. An abusive RPT may weaken capital, liquidity, asset quality, concentration controls and confidence in the institution’s governance.

What is an abusive RPT?

An abusive RPT is a transaction in which a related party uses influence, control or access to obtain an advantage that would probably not have been available to an independent counterparty – or causes the institution to transfer value, assume risk or surrender rights without a sufficient commercial benefit.

Abuse can arise through:

• preferential pricing or credit terms;
• inflated purchases or underpriced asset sales;
• unjustified fees paid to group companies;
• loans granted despite weak repayment capacity;
• insufficient collateral or collateral released without justification;
• guarantees issued without adequate compensation;
• repeated restructuring or waiver of obligations;
• procurement awards influenced by an insider;
• transactions divided to avoid approval thresholds;
• retrospective ratification after execution;
• concealment of the relationship;
• transfer of profits or losses between group entities; or
• use of the institution to support a controller’s wider commercial interests.

IAS 24 defines an RPT broadly as a transfer of resources, services or obligations involving a related party, whether or not a price is charged. Consequently, a guarantee, waiver, collateral release or cost-sharing arrangement can transfer value even where no conventional payment is recorded.

The red-flag framework must therefore look beyond cash movements and accounting descriptions.

The purpose of a red-flag register

A good red-flag register performs four functions.

First, it converts the institution’s RPT policy into specific, testable rules.

Second, it applies those rules consistently across the complete transaction population rather than relying solely on management declarations or manual sampling.

Third, it creates a traceable record showing:

• which rule was triggered;
• which transaction caused the trigger;
• what data was used;
• who investigated it;
• what explanation was received; and
• how the alert was resolved.

Fourth, it identifies patterns that may not be visible from an individual transaction, such as repeated renewals, multiple contracts below approval thresholds or increasing exposure to a common beneficial-owner group.

A red flag is not, by itself, proof of misconduct. It is a reason to investigate. The system should distinguish clearly between:

• an automated alert;
• a validated control exception;
• a policy or regulatory breach; and
• evidence of an abusive transaction.

This distinction protects both the institution and the integrity of the review process.

 designing the register

1. Rules should be deterministic and explainable

A reviewer should be able to reproduce every alert from the underlying records.

 

Each rule should specify:

• required data fields;
• the exact triggering condition;
• exclusions;
• severity;
• escalation route; and
• documentary evidence required to close the alert.

2. Rules should apply across the population

A red-flag system should examine all captured RPTs wherever possible. Sampling remains useful for detailed file review, but it may miss transaction splitting, repeated amendments or cumulative exposure.

3. Aggregation should follow economic ownership

Transactions should be aggregated by:

• legal counterparty;
• individual related party;
• beneficial-owner group;
• controller;
• close-family network;
• common economic purpose; and
• group of connected counterparties.

Five individually small contracts awarded to companies controlled by the same person may represent one material economic arrangement.

4. Rules must be time-sensitive

The system should preserve the chronology of:

• relationship declaration;
• related-party registration;
• proposal initiation;
• negotiation;
• valuation;
• approval;
• contract execution;
• booking;
• disbursement; and
• subsequent amendment.

Without this chronology, retrospective approval and delayed registration cannot be detected.

5. Severity should reflect impact, not merely value

A relatively small transaction may deserve a high-severity classification where:

• a conflicted director participated;
• no approval exists;
• documents were deliberately withheld;
• the counterparty was omitted from the RPT register; or
• assets were transferred on preferential terms.

Conversely, a large routine transaction supported by independent evidence may create an alert that is subsequently resolved without a finding.

Suggested structure

Each rule should be maintained as a controlled record.

Register field	Purpose
Rule ID	Permanent identifier, such as RF-01
Rule name	Clear description of the condition
Abuse risk	The type of misconduct or control weakness addressed
Data sources	Core banking, procurement, HR, treasury or other system
Rule logic	Exact triggering test
Severity	High, medium or low
Responsible reviewer	Function required to investigate
Evidence required	Documents needed to resolve the alert
Escalation route	Management, committee, board or regulator
Regulatory or policy basis	Rulebook, accounting standard and internal policy
Status	Open, under review, validated, closed or overridden
Disposition	False positive, control weakness, breach or suspected abuse
Rule version	Current approved version
Validation date	Date on which the rule was last tested
Alert history	Previous firings and outcomes

 

Changes to rules, thresholds or severity should be approved and recorded. Otherwise, management could weaken a rule after it begins producing uncomfortable results.

A practical RPT red-flag library

The following library reflects common abuse risks for banks and other financial institutions. Institutions should calibrate it to their business model and applicable regulation.

High-severity rules

Rule	Red flag	Why it matters
RF-01	Retrospective ratification	The institution became committed before required approval was obtained
RF-02	Conflicted participation	An interested person participated in initiation, negotiation, valuation, recommendation or approval
RF-03	No approval evidenced	No valid approval record can be produced
RF-04	Register omission	The counterparty was not recorded as related when the transaction occurred
RF-05	Approval authority bypassed	Approval was obtained below the level required by value or risk
RF-06	Preferential terms	Pricing, collateral, tenor, fees or covenants are more favourable than comparable third-party terms
RF-07	Exposure limit breach	Individual or aggregate related-party exposure exceeds an internal or regulatory limit
RF-08	Transaction splitting	Linked transactions were kept individually below an approval or disclosure threshold
RF-09	Value-transfer instrument	A waiver, write-off, collateral release or free guarantee transfers value without adequate compensation

 

Medium-severity rules

Rule	Red flag	Why it matters
RF-10	Unsupported ordinary-course claim	The transaction is labelled routine without evidence of comparable third-party activity
RF-11	Off-balance-sheet commitment	A guarantee, indemnity, undrawn facility or derivative exposure may be understated
RF-12	Non-standard terms	The arrangement departs from approved product, procurement or credit parameters
RF-13	Valuation uncertainty	An illiquid or judgemental asset lacks current independent valuation
RF-14	Repeated dealings with the same party	A pattern may be more significant than any single transaction
RF-15	Period-end proximity	A transaction close to reporting or capital-assessment dates may create window-dressing risk
RF-16	Renewal without fresh challenge	An extension, restructuring or amendment was treated as routine administration
RF-17	No independent control review	A material RPT proceeded without required compliance, risk or independent credit review
RF-18	Material to the related party	The benefit is small to the institution but economically important to the counterparty

 

Lower-severity but important rules

Rule	Red flag	Why it matters
RF-19	Incomplete documentation at approval	Decision-makers may not have received sufficient information
RF-20	Data or evidence inconsistency	RPT, general-ledger, core-banking, procurement or board records do not reconcile

 

Low-severity alerts should not simply be ignored. Several lower-level alerts involving one party may collectively justify a higher-severity assessment.

Detecting the main forms of abusive RPTs

Preferential lending

A related borrower may receive:

• a lower interest rate;
• reduced fees;
• longer maturity;
• weaker collateral;
• optimistic credit assumptions;
• relaxed covenants;
• repeated overdraft excesses;
• refinancing despite arrears; or
• delayed impairment recognition.

The monitoring system should compare the related facility against an appropriate peer group of unrelated borrowers with similar credit risk, product, currency, tenor and collateral.

A simple comparison with the bank’s headline lending rate is not sufficient. A related party might pay the same interest rate as another borrower while receiving materially better collateral, covenant or repayment terms.

Inflated purchases and underpriced sales

A bank may purchase property, securities, technology or services from a connected party at an inflated price. Conversely, it may sell an asset below fair value.

Red flags include:

• a single valuation;
• an outdated valuation;
• use of a connected valuer;
• no open-market process;
• major divergence between valuations;
• an unexplained premium;
• rapid onward sale by the related party; or
• unusual payment conditions.

Procurement and outsourcing favouritism

Abuse may occur through advisory agreements, technology contracts, leases, insurance placements and shared services.

The system should test whether:

• the related party was identified during vendor onboarding;
• competing quotations were genuine;
• selection criteria were changed;
• the lowest or strongest bid was rejected without explanation;
• the contract was repeatedly extended;
• fees increased after approval;
• services were actually delivered; and
• the same bank account, address or beneficial owner appears across several vendors.

Waivers, write-offs and collateral releases

These transactions deserve special attention because value may be transferred without an obvious purchase or payment.

A collateral release should be compared with:

• the remaining exposure;
• current collateral coverage;
• borrower credit quality;
• approval conditions;
• comparable treatment of unrelated customers; and
• the commercial benefit received by the institution.

The same approach should be applied to fee waivers, interest concessions and write-offs.

Concealed guarantees and group support

A bank may support a related company through:

• guarantees;
• comfort letters;
• liquidity commitments;
• back-to-back deposits;
• credit protection;
• side letters; or
• informal undertakings.

These arrangements may not appear in the ordinary loan balance. Treasury, legal and off-balance-sheet records must therefore be included in the monitoring population.

Period-end and window-dressing transactions

Transactions executed shortly before year-end or a regulatory reporting date can temporarily change:

• liquidity;
• deposits;
• loan balances;
• impaired exposures;
• profits;
• capital ratios; or
• concentration measures.

The rule should not assume that every period-end transaction is abusive. It should require analysis of reversals, short holding periods, circular flows and absence of a genuine commercial purpose.

Connecting the red-flag engine to bank systems

An effective register cannot operate solely from manually entered RPT forms. It should draw data from the institution’s wider operating environment.

Core banking and loan-origination systems

These systems supply:

• customer and CIF numbers;
• facility limits;
• outstanding balances;
• interest rates;
• arrears;
• collateral;
• guarantees;
• write-offs;
• restructurings; and
• approval dates.

A customer-level RPT flag should flow into the credit workflow before terms are negotiated or funds are disbursed.

Treasury and investment systems

These provide information on:

• deposits;
• placements;
• securities;
• derivatives;
• foreign exchange;
• investment funds;
• guarantees; and
• liquidity arrangements.

General ledger and accounts payable

These sources can identify:

• advisory fees;
• management charges;
• rental payments;
• asset purchases;
• cost allocations;
• reimbursements; and
• manual journal entries.

Procurement and vendor systems

Supplier names, registration numbers, beneficial owners, directors, addresses, telephone numbers and bank accounts should be matched against the RPT master.

HR and corporate-secretariat records

These systems identify changes in:

• directors;
• senior management;
• controllers;
• key management personnel;
• declared interests;
• close-family relationships; and
• board or committee membership.

The system should conduct a retrospective search when a previously unknown relationship is identified.

KYC and beneficial-ownership records

A legal counterparty may not itself appear obviously related, but its beneficial owner, authorised signatory or controlling shareholder may create the connection.

Accurate beneficial-ownership information is therefore important for identifying conflicts, RPTs and other forms of abuse.

Rule logic should be precise

Examples of reproducible tests include:

Retrospective approval

Trigger where execution date is earlier than required approval date.

The execution date should reflect when the institution became legally or economically committed – not merely the accounting-entry date.

Register omission

Trigger where relationship effective date is on or before the transaction date, but register entry date is after the transaction date.

Transaction splitting

Aggregate transactions where the following are common:

• beneficial-owner group;
• economic purpose;
• project;
• business sponsor; and
• specified monitoring period.

Trigger the rule where the aggregate crosses a higher approval level even though each item remains below the threshold.

Recurrence

Trigger where the number of dealings with the party within the review period exceeds the approved tolerance.

The tolerance should depend on the transaction category. Three loan amendments may be more significant than three routine monthly payments under one properly approved contract.

Preferential pricing

The difference between the related-party term and the comparable-market term should be tested against an approved tolerance, adjusted for risk, collateral, tenor and product characteristics.

Period-end proximity

Trigger transactions occurring within a defined window – perhaps 15 or 30 days – before the reporting date, followed by testing for early reversal or circular movement. The window should be calibrated rather than copied mechanically.

Alert investigation and disposition

Every alert should follow a controlled workflow.

1. Detection

The engine creates the alert and preserves the rule, source data and timestamp.

2. Initial validation

The reviewer confirms that:

• the party match is correct;
• the transaction data are complete;
• the rule was applied correctly; and
• no approved exclusion applies.

3. Business explanation

The responsible business unit explains the commercial purpose and provides supporting evidence.

A verbal explanation should not be sufficient to close a significant alert.

4. Independent challenge

Compliance, risk management, finance, legal or another control function evaluates:

• commercial benefit;
• fairness of terms;
• conflict management;
• approval compliance;
• prudential impact; and
• potential policy breach.

5. Escalation

Depending on severity, the matter may go to:

• senior management;
• the RPT or conflicts committee;
• the board audit committee;
• the risk committee;
• the full board;
• the external auditor; or
• the regulator.

6. Remediation

Possible actions include:

• obtaining missing evidence;
• suspending execution;
• repricing the transaction;
• increasing collateral;
• reversing or terminating the arrangement;
• recovering losses;
• correcting regulatory reports;
• revising delegations;
• updating the related-party register; or
• commencing disciplinary action.

7. Closure

Closure should record a reasoned conclusion such as:

• false positive;
• adequately supported transaction;
• control weakness without financial loss;
• policy exception;
• confirmed breach;
• suspected abusive RPT; or
• matter referred for investigation.

The person responsible for the transaction should not approve closure of their own alert.

Governance of the red-flag framework

First line of defence

Business and operational functions should:

• identify related parties before dealing with them;
• submit complete information;
• explain commercial purpose;
• obtain prior approval;
• monitor performance; and
• respond to alerts.

Risk and compliance functions

These functions should:

• maintain or challenge the rule library;
• review significant alerts;
• test arm’s-length evidence;
• monitor aggregate exposure;
• identify recurring control failures; and
• escalate unresolved matters.

Internal audit

Internal audit should independently assess:

• completeness of the transaction population;
• effectiveness of the rules;
• data lineage;
• adequacy of investigations;
• quality of board reporting;
• inappropriate management overrides; and
• whether closed alerts were properly resolved.

Internal audit should provide assurance rather than routinely becoming the commercial approver of transactions.

Board and board committees

The board should approve:

• the RPT policy;
• materiality and exposure thresholds;
• high-severity rule categories;
• escalation requirements;
• permitted exemptions;
• reporting frequency; and
• override governance.

The board should receive enough information to identify patterns, not merely a list of isolated transactions.

Monitoring aggregate and prudential risk

An RPT red-flag register should be linked to the institution’s exposure monitoring.

The system should aggregate:

• funded balances;
• undrawn facilities;
• guarantees;
• derivatives;
• securities;
• accrued income;
• fees receivable;
• commitments;
• collateral dependencies; and
• indirect exposures through structures or funds.

A high-severity alert should be generated before a limit is breached wherever forward-looking data show that a proposed transaction would create the breach.

A board or supervisory dashboard should present:

Area	Suggested indicator
Alert population	High-, medium- and low-severity alerts
Timeliness	Open alerts by age and overdue investigations
Parties	Alerts by related party and beneficial-owner group
Repeat patterns	Parties with recurrent or repeated alerts
Governance	Retrospective approvals and conflicted participation
Fairness	Preferential-pricing and unsupported arm’s-length claims
Exposure	Current and projected limit utilisation
Documentation	Missing valuations, approvals and agreements
Overrides	Alerts overridden, by approver and reason
Outcomes	False positives, control failures, breaches and suspected abuse
Remediation	Financial recovery, repricing and control improvements
Trends	Comparison with previous quarters and years

 

A zero-alert dashboard should not automatically be interpreted as strong governance. It may indicate incomplete data, overly narrow rules or poor related-party identification.

Testing the effectiveness of the register

The institution should periodically test whether the register actually detects abusive conduct.

Population reconciliation

Compare RPT records with:

• core banking;
• customer and vendor masters;
• general ledger;
• treasury records;
• procurement;
• board declarations;
• KYC ownership records; and
• financial-statement disclosures.

Rule replay

Run rules on historical transactions with known control problems and confirm that they would have generated alerts.

Threshold sensitivity

Test whether small changes in thresholds produce large movements in alerts. This may reveal poorly calibrated limits.

False-positive analysis

Identify rules that generate many alerts but very few valid concerns. The response should be better calibration – not automatic deletion of an inconvenient rule.

False-negative analysis

Review known RPT problems and determine why the system failed to identify them.

Override testing

Examine whether particular managers, business units or related parties have unusually high override rates.

Data-quality testing

Check for:

• missing dates;
• duplicate parties;
• multiple CIFs;
• incomplete beneficial ownership;
• changed counterparty names;
• missing approval levels; and
• unsupported market comparisons.

Common implementation failures

A red-flag framework becomes ineffective where:

• rules exist only in a policy document;
• monitoring depends entirely on self-declaration;
• only loans are covered;
• each transaction is assessed separately;
• related entities are not grouped by beneficial ownership;
• free-text descriptions are used instead of structured data;
• alerts can be closed without evidence;
• severity is based only on transaction value;
• management can override alerts without independent approval;
• rule changes are not version-controlled;
• expired or amended contracts are not reassessed; or
• the board receives totals without transaction-level explanation.

Technology cannot compensate for an incomplete related-party register. If the institution does not know who its related parties are, even the most sophisticated rule engine will miss transactions.

To wrap up,

A red-flag register transforms RPT oversight from a periodic disclosure exercise into a continuous control system.

The strongest frameworks combine:

• a complete related-party and beneficial-owner database;
• automated feeds from core banking and other operating systems;
• deterministic and reproducible rules;
• transaction and group-level aggregation;
• evidence-based investigation;
• independent challenge;
• controlled escalation; and
• board oversight of patterns and remediation.

The most important principle is that an alert should be traceable from rule to transaction, from transaction to evidence, and from evidence to conclusion.

Abusive RPTs are rarely detected through transaction value alone. They are more often revealed by the combination of relationship, timing, pricing, approval, recurrence, valuation and economic purpose. A carefully designed red-flag register brings those signals together and enables the institution – and its supervisor – to identify when an apparently ordinary transaction is, in substance, a transfer of value or risk to an influential related party.

Selected references

IFRS Foundation. IAS 24, Related Party Disclosures. https://www.ifrs.org/issued-standards/list-of-standards/ias-24-related-party-disclosures/

Basel Committee on Banking Supervision. Core Principles for effective banking supervision. https://www.bis.org/bcbs/publ/d573.pdf

G20/OECD Principles of Corporate Governance 2023. https://www.oecd.org/en/publications/g20-oecd-principles-of-corporate-governance-2023_ed750b30-en.html

 

 

A Tool to Manage RPTS

Tool :  Related Party Transaction ( RPT) Management Tool   :    Link

Password : ELEVATECONTROLS90

2. User Guide : Link

3. Demo PPT: Link

The Tool   : In Banking and finance, knowledge only creates value once it can be acted upon.

This is true generally for the financial sector, and more so when  related party dealings are carried out. Understanding the nuances of related-party transaction (RPT) oversight — how exposures aggregate across a beneficial owner, where materiality genuinely bites, and how approval controls can be quietly bypassed — is essential; but understanding on its own rarely changes an outcome.

Insight has to be carried into day-to-day practice, and that is where the right instrument makes the difference.

To close that gap, I’ve built a downloadable tool that turns RPT principles into a working process — capturing transactions, testing materiality, aggregating exposure and assembling a Board-ready view. The tool is free and can be accessed using the password : ELEVATECONTROLS90