Pi Shield

Traditional fraud detection is built on rules. An analyst or engineer writes logic: if the transaction amount is above a threshold, block it. If the card is from a high-risk country, block it. If the customer has no email address, flag it. These rules are clear and auditable, and they work — up to a point.

The problem is that fraudsters adapt faster than rules can be updated. A rule that catches a fraud pattern today becomes ineffective the moment fraudsters change their approach. Writing and maintaining a rule set that remains effective over time requires constant engineering effort, dedicated fraud expertise, and a reactive cycle that always leaves a window of exposure.

Rules are also blunt instruments. A rule that blocks all transactions above a certain amount will stop some fraud, but it will also block a significant volume of legitimate high-value transactions. Every legitimate transaction that is incorrectly blocked is lost revenue, a damaged customer relationship, and a support cost. The industry term for this is a false positive — and false positives are not free.

The alternative is to buy a fraud scoring service from a specialist vendor. These services are powered by large models trained on industry-wide transaction data, and they produce a risk score per transaction. For many businesses, this is a significant improvement over hand-written rules.

But third-party solutions introduce a different set of problems. The client has no visibility into how the score is produced. They cannot tune the model's behaviour for their specific transaction mix, their specific customer base, or their specific risk tolerance. They are paying per-call for a black box that was trained on someone else's data and may not reflect the patterns unique to their business.

There is also the question of cost and dependency. A business that routes every transaction through a third-party fraud vendor is exposed to that vendor's pricing changes, availability guarantees, and data policies. And as transaction volume grows, so does the bill — with no corresponding improvement in accuracy from the client's perspective.

Shield is built in-house and trained on real transaction data from the PayIntelli platform. This means the model learns the actual fraud patterns that appear in transactions processed through our infrastructure — not generic industry patterns from a vendor dataset.

Thresholds are configurable per client. A high-risk merchant and a low-risk merchant do not share the same fraud sensitivity settings. Each client controls how aggressively Shield blocks, matching their own risk tolerance and their own customer profile.

There is no per-call vendor pricing. Shield is operated as a platform capability, and usage is metered transparently per client without the pricing exposure of third-party APIs.

And because Shield is ours, we can investigate, improve, and tune it. When something goes wrong — when false positives spike, or when a new fraud pattern emerges — we have access to everything we need to respond quickly.

Every transaction submitted to Shield receives a numeric risk score between 0 and 100. This score represents the model's assessment of fraud likelihood — higher means more suspicious.

The score is produced by a machine learning model trained on historical transaction data from the PayIntelli platform. The model analyses the full set of signals available in the transaction payload simultaneously, weighting them according to learned patterns from past fraud events. It does not apply sequential rules — it evaluates everything at once, which allows it to detect complex multi-signal fraud patterns that simple rule systems cannot capture.

The score is always returned to the calling system, regardless of the fraud verdict. This gives clients the option to build their own graduated response logic — for example, requiring additional customer authentication for transactions with a score above 50, but only blocking outright for scores above 80.

In addition to the numeric score, Shield returns a simple binary verdict: fraud: "true" or fraud: "false".

This verdict is the primary decision signal for most integration patterns. Calling systems do not need to implement their own threshold logic — Shield applies the client's configured thresholds internally and returns a ready-to-act decision.

The verdict is deterministic for a given transaction and threshold configuration. The same transaction, submitted at the same time, with the same configured thresholds, will always produce the same verdict.

Different clients have fundamentally different risk profiles. A gaming platform with low average transaction values and a customer base accustomed to occasional friction has very different needs from a high-volume merchant selling physical goods to verified returning customers.

Shield does not impose a single, platform-wide fraud threshold. Each client's fraud sensitivity is configured independently in the shield_configs table. The configuration specifies:

• A minimum threshold — the lower boundary of the grey zone (stored for future graduated-response logic)
• A maximum threshold — the decision boundary at which Shield returns fraud: true

When a transaction is evaluated, Shield looks up the threshold configuration for the requesting client. If a client-specific configuration exists, it is used. If no client-specific configuration has been set, Shield falls back to the most recently updated global configuration.

This fallback ensures that new clients are protected immediately, before their specific thresholds have been configured, without requiring manual intervention for every onboarding.

Thresholds can be updated at any time. Changes take effect on the next request — there is no deployment or restart required.

Shield analyses a wide range of signals from every transaction. No single signal is determinative on its own — it is the combination of signals, and the learned relationships between them, that produces accurate fraud assessments.

The signals covered include:

Transaction signals — the amount and currency of the payment, whether the amount is unusually large for the context, the USD-equivalent value, and whether the transaction is in a foreign currency.

Timing signals — the hour of day, day of the week, whether the transaction falls on a weekend, the specific calendar month and day, and how recently the transaction timestamp is relative to the current time. Fraud has temporal patterns — certain hours, days, and times of year see elevated risk — and Shield captures this.

Customer identity signals — whether an email address is present and non-empty, whether a customer name is on file, whether the name appears in the email address (a consistency check), whether the email domain is a personal provider like Gmail or a corporate domain, and an encoded representation of the email domain itself.

Card signals — whether the card is a credit card, debit card, or prepaid card. Prepaid cards in particular are a commonly used instrument in fraud, and the card type is a meaningful signal.

Geography signals — the country of the card, normalised to a standard format, and whether the transaction is domestic or from abroad. Major city indicators are also captured.

Network signals — the first octet of the customer's IP address (a coarse-grained geography and network type indicator), and whether the IP address is a private/local address (which is unusual for a real customer payment and can indicate testing environments or misconfigured integrations).

Payment method signals — one-hot encoded flags for VISA, Mastercard, American Express, Maestro, Diners, and other accepted payment brands.

Authentication signals — whether Strong Customer Authentication (SCA) was applied, which version of the SCA protocol was used, and whether any SCA exemption was claimed and of what type. Transactions that skip authentication or claim unusual exemptions carry higher risk.

Address signals — encoded representations of the billing postal code, state, and city. These are not matched against customer records but provide geographic consistency signals when compared with other transaction attributes.

Real-world transaction payloads are rarely complete. Customers may not have a name on file. SCA data may not have been populated. The customer IP address may be missing or in an unexpected format. Country codes may arrive in different formats from different integration sources.

Shield is designed to handle incomplete and inconsistent data without failing.

All fields are optional from the API's perspective. Missing fields produce safe zero-value features — the model was trained to handle these absences, and a missing field does not cause an error or an artificially elevated fraud score.

Enum fields (payment method, card type, currency, country code, SCA type, exemption type) use fuzzy matching against the known vocabulary. Minor spelling differences or capitalisation inconsistencies are resolved automatically. Values that are too dissimilar from any known value are mapped to a safe NONE default rather than causing a failure.

Country codes may arrive as two-letter ISO codes (e.g. US) or three-letter ISO codes (e.g. USA). Shield normalises both formats automatically.

Every request to Shield must include a valid API key. The key is validated against the Shield product scope before any processing begins. Requests without a key are rejected with HTTP 401. Requests with an invalid or expired key are rejected with HTTP 403. No transaction data is processed for unauthenticated requests.

Shield is a single-tenant processing model — each API call is evaluated in isolation. Transaction data submitted by one client is never visible to, stored alongside, or combined with data from another client. Threshold configurations are loaded per client, ensuring that one client's settings cannot affect another client's fraud decisions.

All communication between the calling system and Shield uses encrypted connections. Transaction data is never transmitted in plaintext. Database connections used by Shield for threshold lookups also enforce encryption in transit.

Database credentials used internally by Shield are not stored in code or configuration files. They are retrieved at runtime from a centralised secrets management service and held only in memory for the duration of the connection. They are never logged or exposed in error responses.

All Shield evaluations produce structured log entries that are written to centralised log storage. Every log entry includes:

• Whether the evaluation succeeded or failed
• The fraud verdict and score produced (on success)
• The error type and source line (on failure)
• A unique request identifier for tracing

Log entries are available to the PayIntelli operations team for investigation, debugging, and performance monitoring.

When Shield encounters an error — a database connection issue, a configuration problem, a model invocation failure — the response includes an error type and the location within the system where the failure occurred. This information is also written to logs with a full traceback, enabling rapid diagnosis.

The most common operational issue that clients may encounter is a missing threshold configuration. If Shield cannot find a threshold configuration for a client (and no global fallback exists), it returns a clear error indicating that threshold configuration is required. This is resolved by inserting the appropriate configuration record through the operations team.

Shield is hosted on AWS Lambda, which provides automatic scaling to handle traffic spikes without pre-provisioning. There is no fixed instance count to manage. Capacity scales with demand.

The underlying SageMaker inference endpoint that hosts the fraud model is a managed, persistent endpoint that is available continuously. It does not need to be started or stopped per request.