Bank accounts of customers, suppliers and the company's own entities, verified before use, masked by default and audited on every read.
Today a supplier's bank change arrives by e-mail, is typed into the ERP by one person, and nobody can say later who verified it.
With Lima the bank details are read where they live, matched on IBAN and account number + bank key + country, assembled field by field and published as one golden record per real bank, with every source key underneath. Payments made to the account and the verification history behind it are one click away, because the transactions sit in the same bed.
Survivorship is per field; the winning source below is the usual one, and a steward's verified edit outranks it.
A bank account is master data with a verification record; a change creates a pending version that stays unusable until verified.
Pairs above the merge line merge; pairs between the lines go to the steward with the two records side by side and the transactions of each; the rest stay apart. Every merge can be undone. The golden records page explains the steps.
Several structures for the same record, each kept as versions with dates.
| Hierarchy | Levels and use |
|---|---|
| Party | party → bank accounts by usage |
| Bank | bank → branch → account |
A pivot can roll the record's measures up any of them; a draft version is validated against the facts before it goes live. See hierarchies.
Written in one language, tested on live rows before they are saved.
| Level | Rules |
|---|---|
| Column | IBAN passes the checksum BIC exists in the bank directory currency is in the code list |
| Row | an active account has a verification with a date and a person the holder name matches the party's legal name or an approved alias |
| Business | no two suppliers share an active account a changed account stays blocked for payment until a second person verifies it payment runs use only active accounts |
| Transactions in the bed | Read from |
|---|---|
| Payments | SAP REGUH; Oracle payments |
| Bank statements | treasury feeds |
| Verification events | workflow |
Measures above are available in the pivot on any hierarchy level, by month or week, with calculated measures beside them. Drill-down opens payments made to the account and the verification history behind it.
Masked to the last four digits for everyone outside treasury and accounts payable; every read of the full number is logged with the reason. The twelve layers apply on every door; see security.
POST /api/v1/golden/bank/status
{
"party": "L-00731",
"usage": "remit-to"
}200 OK
{
"account": "•••• 4471",
"status": "active",
"verified_on": "2026-08-12",
"verified_by": "two-person",
"shared_alerts": 0
}The same call creates the record when nothing matches; related facts are expanded through the cross-reference; page sizes and limits are published per endpoint. See the headless API.
The objects with their real names, the keys in that system's fields, the write interface and what to set up first.
Bank master read from BNKA.
Open the SAP S/4HANA page →Banks and branches read from CE_BANKS_V · CE_BANK_BRANCHES_V (REST: banks · bankBranches).
Open the Oracle Fusion Cloud page →Settlement bank accounts read from Get_Settlement_Bank_Accounts.
Open the Workday page →Bank account read from CONFORMED.BANK_ACCOUNT.
Open the Snowflake page →Names, places and figures are illustrative or anonymised; the pattern is the catalogue's.
A manufacturer moved supplier bank changes into a two-person verification with the evidence attached. A fraudulent change request that arrived by e-mail was caught by the rule that blocks payment to an unverified account.
The golden record is a governed view over rows read in place; a governed replica in your lake is used only where a source is too slow or too limited to query live, and the column says so.
One working day for the first two sources; 3 working days to a production-grade version with rules, hierarchies, security and write-back tested.
Financial services, Industrial manufacturing, Consumer goods, Telecom. The industry pages show the domains each starts with.
Bring two systems that hold the same customers, suppliers or materials. In one working day we connect them, run the match on live rows, review the queue with your steward and publish the first golden view with its API.