Related-party transaction management is usually treated as a governance exercise: identify the transaction, write it up, obtain approval, report it to the board. Yet the quality of that whole process rests on something more basic — whether the institution keeps a complete, accurate and continuously updated related-party database. A transaction can only be reviewed as an RPT once the institution recognises that the customer, borrower, supplier, shareholder, director, fund or counterparty is related to it. Identification is the first control, and the one everything else depends on.
IAS 24 captures the same logic. It requires financial statements to flag the possibility that an entity’s position or performance has been affected by related parties and by transactions and balances with them. For banks, though, the database has to do more than support disclosure. The same underlying data feeds prudential exposure monitoring, conflicts management, arm’s-length assessments, board approvals, regulatory returns, materiality and aggregation calculations, procurement controls, and internal audit and supervisory review.
A register that records each party’s name, relationship class, beneficial-owner group, role, effective date and status is a reasonable starting point. It becomes a control only when it is wired into the institution’s operational systems rather than left as a standalone list.
A network of relationships
A spreadsheet of directors, shareholders and group companies rarely suffices. Relationships change, one individual controls several entities, companies trade under different names, and exposures surface through subsidiaries, funds, guarantees and indirect ownership. The database should therefore be modelled as a network of parties and the links between them.
A single director, for instance, may be connected to close family members, to companies and partnerships he or she controls, to family trusts, to entities controlled by other family members, to funds the group manages, and to suppliers in which he or she holds an economic interest. A corporate shareholder may sit inside a wider beneficial-owner group of holding companies, subsidiaries and associates linked by common control.
This matters especially in banking, where prudential connected counterparties are linked either by control or by economic interdependence. The CBB’s exposure-limit rules describe connected counterparties in exactly those terms — control, and circumstances in which financial trouble at one would likely cause funding or repayment difficulty at another. The database should therefore hold two overlapping but distinct categories: accounting and governance relationships grounded in IAS 24, company law and the institution’s RPT policy; and prudential connections arising from control, common ownership, guarantees and economic dependence. They frequently coincide, but not always.
Developing Database Layers
The party master sits at the centre. Every person or entity receives a permanent internal Related Party ID that never changes, even when the party’s name, role or legal status does. Around that ID the master holds legal and former names, entity type, national or registration identifiers, jurisdiction, the customer, vendor and employee IDs used in source systems, the beneficial-owner group, status, effective dates, source and record owner. Sensitive personal identifiers should be masked in ordinary views and unmasked only for authorised staff.
The relationship layer explains why a party is related. Each relationship gets its own structured record — not a free-text note — identifying the related party, the person or entity through which the link arises, the relationship category, any ownership or voting percentage, whether control is direct or indirect, the number of ownership layers, effective dates, supporting evidence, the validator, and whether the link triggers accounting, prudential or governance requirements. One entity often carries several relationships at once — a group associate that is also controlled by a director — and the database should preserve every one.
The transaction and exposure layer connects the register to real activity. Each RPT record should carry the contract number and source system, product and booking entity, transaction and approval dates, currency and amount, current balance, on- and off-balance-sheet exposure, collateral, pricing against comparable market terms, materiality, approval authority, declared conflicts and recusals, the arm’s-length conclusion, any breaches, and links to the underlying papers. For banking exposures the figure captured must go beyond loan balances to include guarantees, letters of credit, derivatives, securities, undrawn facilities and other contingent items. The CBB’s conventional-bank rules are explicit that related-party exposures should carry clear commercial advantage, be struck at arm’s length and stay within the ordinary course of business — with details recorded, board thresholds set, and effects on capital, liquidity and contagion considered.
The governance layer preserves the decision trail behind each material RPT: the declaration of interest, when the conflict was identified, the committee paper and attendees, who recused themselves, approval conditions, independent valuation or benchmarking, legal and compliance opinions, monitoring requirements, later amendments and the annual review outcome. Together these form an auditable chain from identification through approval to monitoring.
Beyond core banking
The core banking system is the main source of loans, deposits and balances, but never the whole picture. A relationship may originate in HR, the corporate secretariat, a shareholder register, procurement, or a beneficial-ownership declaration — so the architecture has to reach across systems.
From core banking the database should draw customer master data, facilities, limits, balances, rates, arrears, collateral and guarantees, with the Related Party ID mapped to the CIF number and multiple CIFs for one party flagged and consolidated. The core system should raise an RPT indicator at onboarding, at credit proposal, on amendment or renewal, and on any write-off, restructuring or threshold breach — but the database, not the core system, remains the master source for deciding whether a customer is related. In loan origination the flag should flow automatically into the credit proposal, forcing enhanced conflict checks, independent assessment, comparison with ordinary customer terms and the right level of approval, so the connection is not discovered only after disbursement.
Treasury and investment platforms matter because RPT exposure also arises through placements, securities, derivatives, underwriting and investments in group-managed funds, and the database should aggregate these across banking and trading books. A feed from the general ledger and accounts payable catches the non-credit transactions — rentals, consultancy, technology contracts, shared services, management fees, asset sales — that never touch the loan system. Procurement should screen every vendor against the master before appointment and periodically afterwards, checking for declared interests, shared addresses or beneficial owners, competitive quotes and normal commercial terms. HR feeds changes in directors, senior managers and key personnel, where the effective dates are critical: a former director may cease to be related for some purposes, but transactions from the period of the relationship stay reportable. The corporate secretariat supplies board membership, controllers, group structure and recusals, while KYC records often reveal ownership links the business never declared. For investment firms, insurers and fund administrators the same principle extends to fund-accounting, policy and claims systems, unit-holder registers, placement-agent records and reinsurance or takaful arrangements. The rule is constant: connect the master to every system that can create a financial or contractual relationship.
Entity resolution and data quality
Name matching alone produces both missed links and false alerts . Reliable matching combines registration and national identifiers, customer and vendor numbers, beneficial owners, addresses, signatories, directors and former names, with a confidence score that accepts exact identifier matches automatically and routes weaker ones to manual review. A graph database helps with complex groups because it exposes indirect paths — a director controls Company A, which owns Company B, which guarantees a facility to Company C — though a relational design works well provided relationships live in structured tables rather than narrative fields.
The database should be tested routinely for missing identifiers, duplicate parties, multiple CIFs, undocumented relationships, illogical ownership totals, transactions booked before the relationship existed, activity on inactive parties, expired reviews and mismatches between RPT, large-exposure and regulatory reports. BCBS 239 is a useful benchmark even outside its formal scope: integrated data taxonomies, documented and independently validated aggregation, and attention to data capability whenever products, acquisitions or IT changes arrive. In practice this means being able to trace any reported amount back through the source transaction, the source-system record, the mapped Related Party ID, the relationship that drove the classification, and the rule applied.
Workflow, dashboard and sequencing
A sound system supports the full lifecycle: a candidate party is detected; an independent function validates the relationship and evidence; the party is registered with an ID and effective date; the flag is distributed to core banking, credit, treasury and procurement; transactions are captured and aggregated across accounts and legal entities; materiality and arm’s-length tests are applied; approvals are routed away from conflicted decision-makers; balances and conditions are monitored; and management, board and regulatory reports are produced from one controlled dataset.
The management dashboard should show, at a minimum, active related parties and period changes, exposure by party and beneficial-owner group, on- and off-balance-sheet amounts, limit utilisation, items awaiting approval, material and non-arm’s-length transactions, missing valuations, expired declarations, activity on unidentified parties, and the capital and liquidity implications.
None of this requires replacing every system at once. A first stage establishes a controlled central register with standard categories, effective dates, evidence and maker-checker approval. A second maps Related Party IDs to customer, vendor, employee and treasury identifiers and adds daily feeds. A third automates materiality, aggregation, arm’s-length testing, approval routing and reporting. A final stage adds graph analysis, automated entity resolution and continuous reconciliation. The technology can be anything from a secure internal web application to a full master-data platform; what matters is controlled access, reliable interfaces, audit logs, change management and independent validation, sized to the institution’s complexity.
In Retrospect
An effective RPT database is an enterprise control that ties governance information to customers, employees, vendors, shareholders, contracts and exposures. Its central design principle is to organise around relationships and beneficial-owner groups rather than legal counterparty names. Core banking integration is necessary but not sufficient — HR, KYC, procurement, treasury, finance and the corporate secretariat each hold part of the picture. Once those parts are connected, the institution can identify related parties before transactions are executed, aggregate exposure accurately, evidence arm’s-length terms, route approvals correctly, and give its board and supervisors a complete and defensible view of related-party risk.
Selected references
– IFRS Foundation. IAS 24, Related Party Disclosures.
– Basel Committee on Banking Supervision. Principles for effective risk data aggregation and risk reporting (BCBS 239).
Should you wish to try this out :
- Tool : Related Party Transaction ( RPT) Management Tool : Link
Password : ELEVATECONTROLS90
2. User Guide : Link
3. Demo PPT: Link
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
Leave a Reply