Skip to Content (Press Enter)
How is your experience with the OutSystems Community?
Community › Forge › Assets list › Banking Risk & Fraud Assessment Agent
Banking Risk & Fraud Assessment Agent

Banking Risk & Fraud Assessment Agent (ODC)

Supported
Stable version 0.2.2 (Compatible with ODC)
Uploaded on 15 Oct (3 weeks ago) by OutSystems
Banking Risk & Fraud Assessment Agent

Banking Risk & Fraud Assessment Agent (ODC)

Documentation
0.2.2

Customer environment: Import or clone this Forge module into your factory. Your team attaches models, supplies grounding data and documents, integrates callers, and validates outputs. OutSystems does not manage your deployed copy.

To install this Agentic app, you must have the AI Trial Model used in the app (TrialClaudeHaiku4_5) added to your tenant. To do this:

  1. Go to AI Models on ODC Portal.
  2. Click on Add AI Model.
  3. Add the available trial model on the Trial Models tab.

After publishing it for the first time, you can now change the AI model of the agent to one of your organization’s approved models.

To see one example of usage of this pattern, install the companion app Banking Agents Showcase.


Entry point: CallBankingRiskFraudAssessmentAgent

Other modules, processes, or UI in your application should call this Agent only through the public service action CallBankingRiskFraudAssessmentAgent.

Contractual, regulatory, and oversight responsibility for how it is used remains with you as the customer developer and operator.


Input parameters:
UserInput (Data Type: Text): Optional user message or instructions for this run (e.g., investigation focus or clarifications after follow-up).
SessionId (Text): Conversation or trace session identifier (for correlation/logging).
GroundingData (Data Type: Text): Structured or semi-structured context the agent treats as authoritative alongside documents: at minimum banking process type; optionally known entities, reference values, regulatory/lender thresholds, customer risk profile, PEP/sanctions/adverse media references, historical patterns, etc., as JSON or text per your integration.
Documents (Data Type: DocumentStruct List): Case file materials (applications, IDs, income proofs, credit reports, statements, wire instructions, etc.): each item has Type, FileName, and Binary (file content).
Profile (Data Type: AgentProfile): Overrides default agent behavior (tone, verbosity, reasoning depth, risk tolerance, action autonomy, proactivity).
AgentDefinition: (Data Type: AgentDefinition): Optional per-call Agent configuration - extensions for Goal, Workflow, Knowledge, Tools, and Guardrails (appended to default values); OutputDefinition (overrides default values).

Output parameters:
Response (Data Type: Text): Risk analysis result. The format or schema can be defined in the Output section of the AgentDefinition. Defaults to a single raw JSON string (not wrapped in markdown), with required top-level keys: analysis_context (process, documents_analyzed, overall_risk_score, kyc_status, etc.), findings (ordered by severity descending; each finding includes evidence, severity, category, rule, regulatory_relevance, etc.), cross_document_consistency, credit_risk_indicators (with applicable false when not a loan process), recommended_detection_rules (minimum five entries), and methodology_notes (including sar_assessment as specified in the runtime prompt). Parse this text as JSON in your consumer module; you are responsible for correctness, auditability, and any business or regulatory use of the result.

⚠️ Important — Grounding data trust boundary

The provenance hierarchy relies on grounding data to elevate a document from the default Applicant_Assertion class to Institution_Verified. This means the grounding data itself must come from a trusted, system-controlled source — for example, fetched server-side from a database or internal service by the consumer application before calling the agent.

Grounding data must NOT arrive in the same untrusted API request as the documents being analysed. If an external caller can supply both the documents and the grounding data, they can mark their own fabricated documents as Institution_Verified, bypassing the entire trust hierarchy. The consumer application is responsible for enforcing this boundary.