Administrator changes
The administrator changes node on a bank report (administratorChanges) captures every change to the organization's administrators that the customer recorded in this report — new admins, departing admins, role updates, and per‑administrator changes to attorneys and bank‑account access.
Shape
administratorChanges itself is thin: an id and an administratorChange list. The interesting structure lives on the list items, which implement the AdministratorChange interface.
AdministratorChange has two concrete implementations:
BoardMemberChange— wraps a board member, exposesboardMember(with the underlyinguser) andboardMemberRoleChanges(one entry per added/kept role).ExternalAdministratorChange— wraps an external administrator (typically appointed via power of attorney rather than elected). ExposesexternalAdministratorandexternalAdministratorRoleChanges.
Query both with inline fragments — the shared interface fields project at the top level, and the concrete ones go inside ... on BoardMemberChange { … } / ... on ExternalAdministratorChange { … }.
Interface fields
Every AdministratorChange carries:
isNew— the administrator was added in this report.isLeaving— the administrator is being removed in this report.isAuthorizedSignatoryplusisAuthorizedSignatoryChanged— current state and whether it changed.hasRolesChanged— at least one role added or removed.hasChanged—truewhen any of the above istrueor anyattorneyChange.hasChangedistrue.informationFile— a.txtwith bookkeeping information about the administrator.attorneysFile/signedAttorneysFile— the attorneys overview PDF and its signed counterpart.attorneyChanges— list of per‑attorney changes (rights, bank card flag, the affected bank account).
Attorneys and bank accounts
attorneyChanges[].bankAccount exposes accountName, registrationNumber, and accountNumber. rights and bankCard describe what level of access the attorney now has and whether they are entitled to a bank card. Attorney changes are scoped to administrators — there is no top‑level "attorneys" or "bank accounts" node on a bank report; everything attorney‑related is reached via this path.
The attorneyChanges lists are only populated on reports created with the legacy attorney representation (hasDynamicAttorneyModule: false on the bank report). Reports created with the dynamic representation carry their attorney data in dynamicAttorneyChanges instead, and the legacy lists are empty.
On reports created with the dynamic representation, attorneysFile is not the generated overview PDF but the administrator's dynamic attorney documents — their card change documents followed by their aggregated procura document — merged into one PDF, so a consumer still reading this field keeps getting one document per administrator. The merge is a concatenation, so it has no cover page or summary table, its page order follows the underlying documents, and it is built when you request the bytes rather than stored. signedAttorneysFile is always null on those reports: merging re-writes the pages into a new document, which would not carry the sources' signatures.
The merge contains the documents that exist. A change whose document has not been generated — file is null, which is ordinary on reports that required no signature — is simply not in it, and the merged file gives you no way to tell. It is a convenience document, not the record of what the administrator was granted: read dynamicAttorneyChanges for that, where every change is listed whether its document is there or not, signed versions included.
Telling an empty file apart from a failed one
attorneysFile is null both when there is nothing to serve and when a document exists but could not be read — a storage failure, or a source that is not a readable PDF. The two are distinguished by the errors array, not by data:
attorneysFile: nulland no error — there are no documents for this administrator (or your bank does not have the DynamicAttorneys module).attorneysFile: nulland an error withextensions.codeofMERGED_FILE_UNAVAILABLE— documents exist and could not be served. Retry; do not record this as an administrator without attorneys. A partial document is never served, so the file is either complete or absent.
If you store what you read from this field, check errors for that code before treating a null as an absence. One unreadable document affects only that administrator's attorneysFile — the rest of the response, including every other administrator, is unaffected.
Required gate
The whole node is meaningful only when isAdministratorsRequired is true on the parent bank report. When it's false, the package didn't request administrator changes and administratorChanges will be empty.
Where to query
See Querying administrator changes. To reject a package because of an administrator‑related problem, use rejectAuthorizedSignatories: true or — for the per‑member attorney documents — rejectBoardMemberAttorneys: true on rejectBankPackageById.