Securing the Fraud Detection Platform Itself: Admin Roles, Rule Changes, API Keys, Data and Logs

A fraud detection platform decides, in real time, which payments, logins and applications go through, so anyone who can change its rules, models, lists or API keys can switch fraud controls off for exactly the transactions they choose. The platform also concentrates some of the most sensitive data a business holds: device fingerprints, behavioural signals, payment details, identity attributes and the history of every case. Fraud teams spend most of their effort tuning detection and far less on the platform's own admin roles, decision API credentials, feedback data and audit trail. This vendor-neutral guide covers that inside view for fraud engineers, platform owners and security teams, whether the platform is built in house, run on your infrastructure or consumed as a service. For fraud prevention as a discipline see the Fraud Prevention Guide for Digital Businesses; for selecting a platform see the Fraud Prevention Platform Buyer's Guide.

Key takeaways

• Rule and list changes are production changes. An allowlist entry, a lowered score threshold or a disabled rule has the same effect as removing a control, and needs maker-checker approval and an audit trail.
• Insiders are part of the threat model. Fraud platforms are attractive to staff who want to wave through their own or an accomplice's transactions, so separation of duties matters more than in most tools.
• Decision API keys are high value credentials. The key a checkout or login service uses to ask for a score can, if stolen or over-scoped, be used to probe the model or to submit false outcomes.
• Feedback data is an attack path. Chargeback, case outcome and label feeds train the models; corrupt them and the model learns to approve fraud.
• Fail-open versus fail-closed is a security decision. What happens when the platform is slow or unavailable must be agreed in advance, per channel, and monitored.

What makes up a fraud platform's attack surface

Relevant techniques include ATT&CK T1078 Valid Accounts and T1098 Account Manipulation for console access, T1565.001 Stored Data Manipulation for tampering with rules, lists and case outcomes, T1552 Unsecured Credentials for decision API keys left in code, and MITRE ATLAS AML.T0020 Poison Training Data and AML.T0043 Craft Adversarial Data for the model layer. The OWASP API Security Top 10 2023 risks API2 Broken Authentication and API6 Unrestricted Access to Sensitive Business Flows apply to the decision API itself.

Administrative roles and separation of duties

NIST SP 800-53 AC-5 (separation of duties) is the core control. The design goal is that nobody can create a rule or list entry, approve it and close the alerts it would have raised.

• Dedicated admin identities: platform administrators use separate accounts with phishing-resistant MFA (IA-2(1)) from managed devices. See the Privileged Access Workstations Guide.
• Allowlist entries: every allowlist entry for a customer, card, device or merchant should carry a reason, an approver and an expiry. NHI Mgmt Group recommends 90 days as a default maximum, renewed only with fresh approval.
• Self-dealing controls: block analysts from working cases linked to their own customer records, and alert when a staff member's own account, card or device appears in an allowlist.
• Emergency changes: fraud attacks sometimes need a rule in minutes. Allow a documented emergency path with retrospective approval within one business day, rather than letting people share approver rights.

Decision API keys, service accounts and integrations

Every service that calls the platform, and every system the platform calls, uses a non-human identity. Treat each under IA-9 (service identification and authentication) with an owner and a rotation schedule.

• One credential per calling service: separate keys for checkout, login, onboarding and payouts let you revoke one without stopping the others and show which service sent odd traffic.
• Scope by purpose: a key that requests scores should not be able to submit outcomes, change lists or read case data. Where the platform supports it, prefer mTLS or OAuth client credentials with short-lived tokens over static keys. See the API Key Management Guide.
• Protect outbound credentials: credentials the platform uses to block cards or lock accounts can be abused to cause mass denial of service to customers. Store them in a secrets manager, limit them to the specific actions, and alert on volume spikes.
• Client-side keys are public: keys embedded in web or mobile collection SDKs are visible to anyone. Rely on server-side validation and integrity signals, never on keeping those keys secret.
• Webhooks: verify signatures on decision and case webhooks and rotate signing secrets. See the Webhook Secrets Security Guide.

See also the Service Account Security Guide.

Models, labels and the feedback loop

Machine learning fraud models learn from outcome labels: chargebacks, confirmed fraud, false positive reviews. That loop is an integrity risk as well as a quality one.

• Label provenance: record who or what set each label and from which source. Alert on unusual volumes of "not fraud" outcomes from one analyst or one feed.
• Controlled promotion: models move from training to shadow scoring to production through an approved pipeline, with the artefact hash recorded at each step (CM-3). Keep the previous model ready for rollback.
• Probing resistance: rate limit and monitor decision API callers for patterns that look like systematic testing of thresholds. See the AI Data Poisoning and Backdoors Guide.
• Governance: the NIST AI Risk Management Framework (Govern, Map, Measure, Manage) gives a structure for documenting model owners, intended use and monitoring. See the Fraud Rules and Machine Learning Models Guide for model design.

Data protection and retention

• Minimise and segregate: fraud platforms often receive more personal data than they need. Agree a field list with the privacy team and tokenise payment card numbers before they reach the platform where possible.
• Export controls: bulk case export and report downloads are a likely exfiltration route. Restrict them to named roles and alert on large exports (AC-6(9)).
• Retention: set retention for events, features and cases to match legal and regulatory needs (SI-12), and confirm backups and test environments follow the same rules.
• Test data: do not copy production case data into development or vendor support environments without masking.

Availability and failure modes

Decide per channel whether a timeout or outage fails open (approve) or fails closed (decline or hold), document it, and alert when fallback is in use. Attackers who learn that a channel fails open have a reason to degrade the platform. Keep fallback rules simple and tested, and include the platform in business continuity plans (CP-9, CP-10), including restore of rules, lists and model versions, not only data.

Logging and monitoring

Forward platform logs to a SIEM that fraud platform administrators cannot alter (AU-9). Priority events:

• Rule, threshold, list and model changes, with author and approver.
• Role grants, new API keys, SSO configuration changes and admin sign-ins.
• Bulk exports, unusual case closure patterns and labels changed after the fact.
• Fallback mode activation and decision API error spikes.

See the SIEM Guide.

Hardening an existing platform: a phased approach

1. Inventory (weeks 1 to 2): list users and roles, API keys, integration accounts, outbound credentials, allowlists and the fail-open or fail-closed setting for each channel.
2. Roles and approval (weeks 2 to 6): move to SSO with MFA, split author and approver roles and switch on maker-checker for rules and lists. Run the first changes in shadow mode and keep the previous rule set exportable for rollback.
3. Credentials (weeks 4 to 8): issue one credential per calling service, narrow scopes, move secrets to a secrets manager and rotate everything issued during deployment.
4. Allowlist clean-up (weeks 6 to 10): add owner, reason and expiry to every entry and remove entries nobody claims.
5. Logging and model controls (weeks 8 to 12): forward logs, build the alerts above and put model promotion under change control.
6. Exercise (quarter end): simulate a platform outage and a rogue rule change, and confirm detection and recovery.

Timings are NHI Mgmt Group recommendations; large payment estates may need longer for credential replacement.

Decision guidance

• Service or self-hosted: a service moves infrastructure security to the provider but your rules, lists, users and API keys remain your responsibility. Ask for an exportable admin audit log and SSO before signing.
• Small teams: where the same two people write and approve rules, require each to approve the other's changes and send a weekly change report to someone outside the team.
• Consortium and shared data: data shared with a consortium or provider network is governed by contract; confirm what leaves, in what form, and who at the provider can see it.

Detection and measurement

• Change approval rate: percentage of rule, list and model changes with an independent approver.
• Allowlist hygiene: percentage of entries with owner, reason and expiry; number expired but still active.
• Credential scope: number of calling services sharing a credential (target zero).
• Admin coverage: percentage of administrators on dedicated MFA accounts.
• Fallback time: minutes per month any channel spent in fallback mode.

Framework mapping

Common failure patterns

• Permanent allowlists: entries added to stop customer complaints never expire and are never reviewed.
• Author approves own rule: maker-checker exists in the product but is switched off for speed.
• One key for everything: every channel uses the same decision API key, embedded in several codebases.
• Unexamined labels: outcome labels are trusted without knowing who set them.
• Silent fail-open: timeouts approve transactions and nobody alerts on it.
• Bulk export by default: every analyst can download full case data.

Practitioner checklist

• Inventory roles, API keys, integration and outbound credentials, allowlists and fallback settings.
• Use SSO with phishing-resistant MFA and dedicated accounts for administrators.
• Separate rule authors from approvers and turn on maker-checker for rules, lists and models.
• Give every allowlist entry an owner, reason and expiry.
• Issue one scoped credential per calling service and store secrets in a secrets manager.
• Record label provenance and control model promotion with rollback.
• Restrict bulk export and alert on large downloads.
• Agree and monitor fail-open or fail-closed behaviour per channel.
• Forward logs to a SIEM the platform admins cannot change.

Standards and references

• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• NIST: AI Risk Management Framework
• MITRE ATLAS: Poison Training Data
• MITRE ATT&CK: Stored Data Manipulation
• OWASP: API Security Top 10 2023
• NCSC: Secure system administration

Related NHI Mgmt Group resources: Fraud Prevention Guide for Digital Businesses · Fraud Prevention Platform Buyer's Guide · Fraud Prevention Platform RFP Template · Securing the PAM Vault Itself