Securing Vendor Bank Details in D365 F&O: A Complete Guide to the Table Permissions Framework (TPF)

An AP clerk sees a legitimate $250,000 vendor invoice approved for payment. Ten minutes before the EFT file generates, they swap the bank routing number to their personal shell company account. The ERP shows a perfectly matched invoice and a zero balance. The vendor calls a week later asking where their money is.

This is textbook ghost vendor modification fraud. It happens because standard D365 F&O security configurations frequently over-provision access to the VendBankAccount table. ITGC auditors from the Big 4 actively hunt for this specific control gap — if your transactional AP clerks can view and edit vendor bank routing numbers, you will receive an automatic significant deficiency finding.

Why XDS Fails for Field-Level Security

When tasked with masking sensitive fields like bank accounts or employee salaries, many IT Directors attempt to use Extensible Data Security (XDS). This is a fundamental architectural mistake.

XDS is a row-level security engine. It filters records based on user context — preventing a European user from seeing North American vendor records. It is not designed to hide specific columns on a form while leaving the rest of the record visible.

⚠️ Critical limitation: Extensible Data Security policies are bypassed by OData endpoints and Data Entities. A user can click Open in Excel on the vendor list, authenticate via OData, and read or modify protected bank account numbers directly from the spreadsheet — bypassing any XDS policy you configured in the UI.

To achieve persistent, impenetrable field-level security that spans the user interface, the API layer, and the data management framework — you must use the Table Permissions Framework.

The Architecture of TPF — AOSAuthorization

TPF is Microsoft's explicit mechanism for field-level security in D365 F&O. Instead of hiding rows, it locks down specific columns deep within the Application Object Tree (AOT). When a field is secured via TPF, the system kernel strips it from the UI, drops it from Excel add-in queries, and blocks it from OData endpoints — unless the user possesses a security privilege explicitly granting access to that exact field.

The entire framework runs on the AOSAuthorization AOT property. For TPF to activate on a table, two conditions must be true:

The table itself must have AOSAuthorization set to Yes
The specific field must have its AOSAuthorization set to CreateReadUpdateDelete

Because vendor bank fraud is a universal risk, Microsoft has already locked down the standard VendBankAccount table. The AOSAuthorization properties are already active on AccountNum (bank account number), RegistrationNum (routing number), and SWIFTNo. Your job is to engineer the security roles to interact with this correctly.

Step-by-Step: Locking Down VendBankAccount

If a table is TPF-enabled, granting broad Update access to the table does NOT grant access to the TPF-secured fields. Access to specific fields must be explicitly granted line-by-line in the privilege.

1Strip Implicit Access from AP Roles

Navigate to System administration → Security → Security configuration. Locate your AP Clerk roles and confirm they do not contain the duty VendBankAccountsMaintain (Maintain vendor bank accounts). If they do — remove it. This duty grants implicit access that bypasses your intended restrictions.

2Build the View-Only Privilege for AP Clerks

In Security Configuration, create a new privilege named VendBankAccount_ViewRestricted. Add the VendBankAccount table to the Permissions node. Set table Grant access to Read. Do NOT add any specific fields to this node. Assign this privilege to your AP Clerk role. Result: the clerk sees the bank account ID they need to select in a payment journal, but AccountNum and RegistrationNum columns render completely blank in their browser and in Excel exports.

3Build the Update Privilege for Master Data Team

Create a new privilege named VendBankAccount_UpdateSecure. Add VendBankAccount table with Grant access set to Update. Expand the table node → click Add references → select AccountNum, RegistrationNum, and SWIFTNo specifically. Set Grant access to Update for each field. Bundle this privilege into a dedicated Duty assigned strictly to your Vendor Master Data role — not to anyone who processes invoices or generates payments.

Role Mapping — Segregation of Duties

TPF configuration is useless if your role assignments violate SoD. The people who create vendors must never be the people who pay vendors.

Restricted Access

AP Clerks

Process invoices and execute payment runs. Can see Bank Account ID to select in payment journals. Cannot see or edit raw routing numbers or account strings. Ghost vendor exploit eliminated.

Full Field Access

Master Data / Treasury

Centralized, highly restricted group. Do NOT process invoices and do NOT generate payments. Exclusive right to create vendors and update VendBankAccount table. Verify all bank changes out-of-band before entry.

⚠️ Critical — System Administrators

SysAdmin Bypasses TPF Entirely

Any user holding the System Administrator role completely bypasses the Table Permissions Framework. If your developers or helpdesk hold persistent SysAdmin in production, your TPF configuration still fails the ITGC audit. Use time-bound Entra ID PIM for all IT elevated access.

What ITGC Auditors Actually Test

Auditors will not just take your word for it. They will ask for a Security Configuration export and trace the VendBankAccount table permissions to identify exactly which privileges grant Update access to the AccountNum field. They then map those privileges to Duties, Duties to Roles, and Roles to active Entra ID users.

If that final list of users contains anyone outside your documented, approved Master Data or Treasury team — you fail the control.

By using TPF, you establish a mathematically provable, kernel-level lock on your most sensitive financial data — one that OData integrations, Excel exports, and rogue AP clerks cannot bypass.

A complete D365 F&O security review — identifying VendBankAccount access exposure, TPF configuration gaps, and SoD conflicts in your payment cycle — delivered within 48 hours. No system access required.

📱 Request Free Security Review 🔍 Try Free Dashboard