SUNANDO ROY – On Banking, Finance and Society

A related-party register tells a financial institution who is related. Transaction capture tells it what the institution has done with that related party. This distinction is fundamental. A bank may maintain an accurate list of directors, controllers, senior managers, group entities and connected businesses, yet still fail to identify the risks arising from loans, deposits, guarantees, contracts, asset transfers or fee arrangements involving those parties.

An effective RPT framework must therefore connect two controlled datasets:

1. the related-party master, containing the parties and the nature of their relationships; and
2. the transaction population, containing every transfer of resources, services or obligations involving those parties.

The central principle is to capture economic substance, not merely legal form. A transaction should not disappear from the RPT population simply because it has no conventional purchase price, is described as an internal arrangement or is recorded outside the lending system.

IAS 24 defines an RPT as a transfer of resources, services or obligations between the reporting entity and a related party, regardless of whether a price is charged. That broad definition has major practical implications for banks and other financial institutions.The Basel Core Principles apply the concept more widely. Related-party transactions can include on- and off-balance-sheet credit exposures as well as service contracts, asset purchases and sales, construction arrangements, leases, derivatives, borrowings and write-offs.

A sufficiently comprehensive capture system should therefore accommodate transactions such as:

• credit facilities and loans;
• deposits or funding accepted from related parties;
• guarantees and indemnities;
• collateral releases or substitutions;
• waivers, restructurings and write-offs;
• purchases and sales of property or other assets;
• outsourcing and service contracts;
• management and advisory fees;
• shared-service and cost-allocation arrangements;
• investments in related or group-managed funds;
• leases;
• insurance or brokerage placements;
• derivative and treasury transactions; and
• other transfers of resources or economic benefits.

A zero-value entry may still be economically significant. A guarantee issued without a fee, a collateral release, a concessionary extension of tenor or the waiver of a contractual right may transfer value even though no immediate cash payment is recorded.

The transaction system should consequently ask not only, “How much was paid?” but also:

What resource, service, obligation, right or risk was transferred?

The transaction record should answer six questions

Every captured transaction should enable a reviewer, board member, auditor or supervisor to answer six basic questions:

1. Who was the related party?
2. What was provided, received, amended or surrendered?
3. Why did the institution enter into the transaction?
4. What was its full economic value and continuing exposure?
5. Was it conducted on terms comparable with those available to an unrelated party?
6. Was it properly approved before the institution became committed?

A well-designed record should not merely reproduce accounting entries. It should capture the full decision, exposure and governance history.

Essential RPT data fields

Data area	Information to capture
Identification	Unique transaction ID, related-party ID, legal counterparty, beneficial-owner group and source-system reference
Timing	Initiation date, approval date, execution date, booking date, disbursement date and maturity date
Classification	Transaction type, product, booking entity, business unit and economic-purpose tag
Measurement	Original value, outstanding exposure, currency, contingent exposure and maximum potential exposure
Pricing	Interest rate, fee, rent, valuation, collateral margin and pricing basis
Governance	Approval authority, approval timing, abstentions, recusals and conditions imposed
Arm’s-length evidence	Market quotations, independent valuation, comparable transactions and credit-pricing analysis
Prudential impact	Capital, liquidity, asset quality, exposure limits, encumbrance and off-balance-sheet implications
Monitoring	Current status, arrears, amendments, covenant breaches, exceptions and review date
Evidence	Contracts, valuations, approvals, conflict declarations, committee minutes and supporting correspondence

 

Mandatory structured fields should be used wherever possible. Important information such as transaction type, approval timing and pricing basis should not be left only in narrative descriptions.

1. Capture the correct related party

The related-party field should be selected from the controlled party register rather than entered manually.

This establishes a reliable connection between:

• the transaction;
• the legal counterparty;
• the institution’s customer or vendor number;
• the person or entity creating the relationship;
• the beneficial-owner group; and
• all other transactions involving the same group.

Manual free-text entry creates risks such as spelling variations, duplicate counterparties and incomplete aggregation. The transaction should be linked through a stable Related Party ID and beneficial-owner group rather than relying only on the name appearing on the invoice or account.

The system should also confirm whether the party was included in the register on the transaction date. A party entered only after a transaction was approved may indicate delayed identification, an incomplete declaration or ineffective screening.

2. Record the transaction’s economic purpose

A clear economic-purpose tag helps distinguish legitimate commercial activity from transactions designed primarily to transfer value or favour a related party.

Examples include:

• financing a specified property development;
• renting premises for a branch;
• purchasing an operating asset;
• receiving IT support from a group service company;
• placing insurance through a connected intermediary;
• investing seed capital in a group-managed fund; or
• sharing regional management costs.

Descriptions such as “general purposes”, “group arrangement” or “business requirement” are usually too vague.

The purpose field should explain:

• the business need;
• the expected benefit to the institution;
• the basis for selecting the related party;
• the alternatives considered; and
• why the arrangement is in the institution’s interest.

The description should be capable of appearing in a credit paper, committee submission or board pack without requiring substantial reconstruction.

3. Capture value and exposure separately

The original transaction value and the outstanding exposure are not always the same.

The transaction record should therefore distinguish between:

• approved limit;
• original contract value;
• amount disbursed;
• current outstanding balance;
• undrawn commitment;
• contingent exposure;
• replacement cost or market value;
• accumulated payments;
• collateral value; and
• maximum possible exposure.

The relevant counterparty may differ according to the exposure: the borrower for a credit facility, the person guaranteed for a guarantee, the security issuer for a security holding and the contractual counterparty for a derivative. An RPT platform should therefore obtain exposure data from more than one source system.

4. Integrate transaction capture with core banking and other systems

A standalone form is useful for supervisory assessment or manual review, but a production RPT framework should receive information from the institution’s operational systems.

The core banking system can supply:

• CIF and account numbers;
• loan and deposit balances;
• facility limits;
• disbursements;
• interest rates;
• repayment status;
• past-due amounts;
• collateral records; and
• restructuring or write-off information.

The RPT flag should ideally be attached to the customer master or CIF. When a related party has several CIFs, the system should consolidate them.

Loan-origination platform

The loan-origination system should check the RPT master when a proposal is created. A positive match should trigger:

• enhanced conflict checks;
• independent credit analysis;
• arm’s-length testing;
• approval escalation;
• restricted access for conflicted persons; and
• confirmation that approval was obtained before disbursement.

Treasury system

Treasury integration captures deposits, placements, securities, derivatives, foreign-exchange transactions and other exposures that may not appear in ordinary loan records.

General ledger and accounts payable

General-ledger and payment data can identify:

• management fees;
• rental payments;
• shared expenses;
• consulting costs;
• asset purchases;
• reimbursements; and
• payments to related suppliers.

Procurement and vendor-management systems

A supplier may be related even though it has no customer relationship with the institution. Vendor onboarding should therefore screen beneficial owners, directors, addresses and bank accounts against the related-party database.

HR and corporate-secretariat systems

Changes involving directors, controllers, senior managers and key management personnel should update the related-party register and trigger retrospective transaction searches where necessary.

Fund, insurance and investment platforms

Asset managers, investment firms and insurers may need interfaces with:

• portfolio-management systems;
• fund-accounting platforms;
• policy and claims systems;
• brokerage records;
• unit-holder registers;
• investment committee tools; and
• placement-agent databases.

The objective is not necessarily to store every transaction in one application. It is to establish a controlled data layer through which RPTs can be identified, matched, aggregated and reviewed.

5. Record the pricing basis, not just the price

An arm’s-length assessment requires more than a checkbox stating that the terms were commercial.

The transaction record should identify the pricing basis, such as:

• standard published terms;
• terms granted to a comparable unrelated customer;
• competitive quotations;
• independent valuation;
• observable market price;
• external benchmark;
• cost-plus methodology;
• credit-risk-based pricing;
• actuarial or investment valuation; or
• another documented methodology.

For a credit facility, the comparison may need to consider:

• borrower creditworthiness;
• facility size;
• tenor;
• collateral;
• repayment structure;
• currency;
• guarantees;
• covenants;
• fees; and
• probability of default.

A nominally identical interest rate does not prove arm’s-length treatment when the related party has weaker collateral, a longer tenor or less restrictive covenants.

For property and asset transactions, a valuation should be sufficiently current, independent and based on an appropriate valuation methodology.

Evidence of arm’s length

Useful evidence includes:

• an independent and current valuation;
• comparison with third-party terms;
• complete and contemporaneous documentation;
• compliance review;
• internal-audit coverage; and
• confirmation that the counterparty was already in the RPT register.

These indicators should not all carry equal weight. An independent valuation or genuine third-party comparison generally provides stronger evidence than a management statement that the terms are market based. Internal audit coverage provides assurance over the process, but it does not by itself prove that a particular price was fair.

6. Capture approval timing accurately

The approval-timing field is one of the most important controls in an RPT system.

Possible classifications might include:

• approved before execution;
• approved after negotiation but before commitment;
• ratified after execution;
• retrospectively approved;
• approval not evidenced;
• outside delegated authority; or
• exempt under an identified policy provision.

Approval obtained after the agreement was signed, funds were transferred or the institution became legally committed is not equivalent to prior approval.

A database should preserve separate dates for:

1. proposal initiation;
2. commercial agreement;
3. management approval;
4. committee approval;
5. board approval;
6. contract execution; and
7. financial booking or disbursement.

This allows the system to detect retrospective approval and possible circumvention of governance requirements.

7. Identify conflicted persons and record recusal

An RPT record should identify every director, senior manager or decision-maker with a personal, family, ownership or group interest in the transaction.

It should then record:

• the nature of the conflict;
• when it was declared;
• whether the person received the papers;
• whether the person attended the discussion;
• whether the person voted;
• the time of departure and return, where applicable; and
• the remaining quorum.

A generic statement that “the interested director abstained” may be inadequate where the director influenced the transaction before the formal meeting or participated in negotiating the terms.

8. Capture qualitative risk attributes

Not every material RPT will be identified through its monetary value.

A smaller transaction may warrant heightened review when:

• pricing is non-standard;
• collateral is weak or unusual;
• the valuation is uncertain or illiquid;
• the arrangement has been repeatedly renewed or amended;
• it is material to the related party even though small for the institution;
• the business sponsor has a personal interest;
• there was no competitive selection process;
• documentation is incomplete;
• payment terms are unusually favourable; or
• several linked transactions appear to have been separated.

These attributes can be converted into red flags or a qualitative materiality score.

 

9. Assess the prudential impact

An RPT assessment should not end with accounting disclosure and board approval.

The transaction-capture process should identify potential effects on:

• regulatory capital and the capital adequacy ratio;
• related-party and large-exposure limits;
• liquidity ratios;
• asset quality and impairment;
• collateral coverage;
• asset encumbrance;
• concentration risk;
• off-balance-sheet commitments;
• contagion within the wider group; and
• recovery and resolution planning.

A connected deposit may improve short-term liquidity but create concentration and withdrawal risk. A guarantee may have limited immediate accounting impact but create a significant contingent exposure. A below-market asset sale may reduce capital through an economic loss even if it generates cash.

10. Aggregation must follow economic relationships

Capturing each transaction individually is only the beginning. The system must aggregate transactions across:

• accounts;
• products;
• branches;
• legal entities;
• currencies;
• reporting periods;
• subsidiaries;
• related persons; and
• beneficial-owner groups.

The application should also search for possible transaction splitting.

For example, five contracts of BHD 90,000 awarded to entities under common control should not necessarily be treated as five unrelated transactions below a BHD 100,000 approval threshold. The system should test common ownership, purpose, timing, approver and contractual interdependence.

Aggregation should be available on at least three bases:

• gross transaction value during the period;
• outstanding exposure at the reporting date; and
• maximum potential or contingent exposure.

These measures answer different risk and disclosure questions.

11. Build a reliable evidence trail

Every material record should link to its supporting documents, including:

• signed agreement;
• credit proposal;
• valuation report;
• quotations or tender documents;
• market-comparison analysis;
• conflict declaration;
• legal and compliance review;
• committee paper;
• minutes and approval;
• collateral documentation;
• payment records; and
• subsequent amendments.

The system should preserve document versions and timestamps. Evidence created after a supervisory, audit or regulatory query should be distinguishable from evidence that existed when the transaction was approved.

This is especially important for claims that:

• market comparisons were performed;
• the board gave prior approval;
• a conflict was declared;
• an independent valuation was considered; or
• the related party did not receive preferential terms.

A practical transaction-capture workflow

An effective workflow can follow ten stages:

1. Initiation. A transaction proposal is entered or received from a source system.
2. Screening. The counterparty and beneficial owners are checked against the related-party master.
3. Classification. The transaction type, purpose and relevant relationship are established.
4. Measurement. Funded, unfunded and potential exposures are calculated.
5. Arm’s-length testing. Pricing, collateral and contractual terms are compared with market or third-party terms.
6. Risk assessment. Quantitative materiality, qualitative attributes and prudential effects are assessed.
7. Conflict control. Interested persons are identified and excluded from inappropriate participation.
8. Approval. The transaction is routed to the authority specified by the policy.
9. Execution and monitoring. Execution is permitted only after required conditions are met, followed by continuing exposure monitoring.
10. Reporting. The record feeds management, board, regulatory and financial-statement reports.

Material amendments, renewals, restructurings and waivers should restart the relevant parts of this process rather than being treated as routine administration.

What should supervisors and internal auditors test?

A supervisory or internal-audit review should not examine only the transactions already recorded in the RPT database. That tests accuracy but not completeness.

Reviewers should independently search source systems for transactions that may have been omitted. Useful procedures include:

• matching the related-party master against the customer and vendor databases;
• reviewing payments to group companies and connected suppliers;
• examining manual general-ledger entries;
• testing facilities approved near materiality thresholds;
• identifying multiple CIFs or vendor codes for the same party;
• comparing board declarations with KYC beneficial-ownership data;
• reviewing write-offs, fee waivers and collateral releases;
• checking transactions entered shortly before or after a person became related;
• reconciling RPT reports with large-exposure and financial-statement disclosures; and
• tracing selected records back to contracts, approvals and accounting entries.

A transaction population containing no exceptions is not necessarily evidence of strong controls. It may instead indicate narrow definitions, weak capture or excessive reliance on self-declaration.

Therefore,

 

A strong RP transaction record captures more than the date, party and amount. It explains the economic purpose, identifies the full exposure, records the pricing basis, preserves evidence of arm’s-length terms, documents conflicts and approvals, evaluates prudential effects and supports aggregation across the wider connected group.

For banks, the process must be connected to core banking, credit, treasury, finance, procurement, HR and corporate-secretariat systems. For investment firms, insurers and asset managers, it should also cover portfolio, fund, policy, claims and intermediary platforms.

The central design principle is simple:

Capture every transfer of value or risk involving a related party, assess it before commitment, and preserve enough evidence for an independent reviewer to reconstruct the decision.

When this principle is embedded in the institution’s systems, RPT capture becomes more than a disclosure exercise. It becomes an early-warning mechanism against preferential treatment, conflicts of interest, concentration risk, financial leakage and misuse of institutional resources.

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

Basel Committee on Banking Supervision. Principles for the management of credit risk. https://www.bis.org/bcbs/publ/d595.pdf

A Tool for RPT Management:

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 link and  password : ELEVATECONTROLS90