Integrating with the fraud screening system of the bank

FTM for High Value Payments defines an ISF format for both the fraud screening request and fraud screening response messages that are used to interface with the fraud screening service. It is expected that customers likely need to develop custom mappers to transform the ISF to or from the messages that are used by the service of the bank.

Fraud screening request

The fraud screening request message uses the full ISF content of the associated payment message. It contains the payment amounts and all of the details of the debtor, creditor, and respective financial institutions.

Figure 1. Example ISF for fraud screening request messages
<isf:ISFMessage xmlns:isf="http://www.ibm.com/xmlns/prod/ftm/isf/v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <Header>
      <BusinessConcept>HVP_OUTGOING_FRAUD_REQUEST</BusinessConcept>
      <TransactionId>16853030</TransactionId>
      <RequestID>16858005</RequestID>
   </Header>
   <isf:CreditTransfer>
      <ChargeBearer>CRED</ChargeBearer>
      <EndToEndIdentification>E2E-TxPrefix20160513223041395000584</EndToEndIdentification>
      <PartyRole xsi:type="isf:DebtorRole">
            ...    </PartyRole>
      <PartyRole xsi:type="isf:DebtorAgentRole">
            ...    </PartyRole>
      <PartyRole xsi:type="isf:CreditorAgentRole">
            ...    </PartyRole>
      <PartyRole xsi:type="isf:CreditorRole">
            ...    </PartyRole>
      <PaymentExecution xsi:type="isf:ISFPaymentInstruction">
         <CreationDate>2016-05-14T02:30:41Z</CreationDate>
         <Identification>20160516021200201BFFF0000000584</Identification>
         <ProcessingInstructions>
            <LocalInstrument>CONSUMER</LocalInstrument>
            <ServiceLevel>
               <ServiceLevel CodeIssuer="ExternalServiceLevel">SDVA</ServiceLevel>
            </ServiceLevel>
         </ProcessingInstructions>
         <AgentRole xsi:type="isf:InstructingAgentRole">
               ...    </AgentRole>
         <AgentRole xsi:type="isf:InstructedAgentRole">
               ...    </AgentRole>
         <ClearingSystemReference>001</ClearingSystemReference>
         <SettlementInstruction>
            <InterbankSettlementAmount Currency="EUR">332.1</InterbankSettlementAmount>
            <InterbankSettlementDate>2016-05-13T00:00:00</InterbankSettlementDate>
            <PartyRole xsi:type="isf:SettlementInstructionSystemRole">
                  ...    </PartyRole>
            <SettlementMethod>CLRG</SettlementMethod>
         </SettlementInstruction>
      </PaymentExecution>
      <PaymentObligation xsi:type="isf:ISFPaymentObligation">
            ...    </PaymentObligation>
      <AlternativeTransactionIdentification>
         <IdentificationIssuer>MsgId</IdentificationIssuer>
         <IdentificationValue>M20170313IBMFININST1uc1.1x...000584</IdentificationValue>
      </AlternativeTransactionIdentification>
      <TransactionIdentification>TxPrefix....20160513223041395000584</TransactionIdentification>
   </isf:CreditTransfer>
</isf:ISFMessage>
Note: This sample XML is only indicative of the document structure.
Model changes
  1. Create an appropriate FTM format in the customer application model. This format defines the format and structure of the message that is sent to the fraud screening service.
  2. Copy the FTM mapper ISFToFraudScreeningRequestMapper from the Common IP model into the customer application model. Modify the following properties:
    • Name
    • ID
    • Description
    • Format (select new format)
  3. Copy the FTM channel Fraud Screening Request from the Common IP model into the customer application model. Modify the following properties:
    • Format (select the new format)
    • Mapper (select the new mapper)
  4. Review the other properties, such as CCSID, validation, and transport, and change them as needed.
  5. Save and validate the changes.
  6. Extract and deploy a new config script.
Note: Due to a known issue in the FTM Configuration Data Extractor, the artifacts that were copied from the Common IP model need to be deleted from the Common IP model after they are copied.
Code changes
  1. Implement an IBM® App Connect Enterprise message model to use with the new format that was defined in step 1 of the model changes. Or, import or select a suitable XML schema or other type of format descriptor to use with it.
  2. Implement a new outbound mapper by using a standard FTM mapping template or by copying an existing outbound mapper. Create the mapper in a customer-named application IBM App Connect Enterprise library. Ensure that the label of the mapper is changed to match the name that was assigned in step 2 of the model changes.
  3. Ensure that the mapper is added to the customer application event processing wrapper flow. Ensure that the Datasource property is promoted and connected to the Datasource property of the wrapper flow.
  4. Rebuild and deploy the new customer workspace.

Fraud screening response

The fraud screening response message uses the ISF acknowledgment structure. All of the response types are similar, with only the BusinessConcept and TransactionStatus that change to reflect the outcome.
Table 1. ISF fraud response values
Operation BusinessConcept TransactionStatus or StatusCode
Fraud Screening Response HVP_FRAUD_RESPONSE ACTC
Fraud Screening Response Reject HVP_FRAUD_RESPONSE_REJECT RJCT
Fraud Screening Response Pending HVP_FRAUD_RESPONSE_PENDING PNDG
Figure 2. Example ISF for fraud screening response messages
<isf:ISFMessage xmlns:isf="http://www.ibm.com/xmlns/prod/ftm/isf/v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <Header>
      <BusinessConcept>HVP_FRAUD_RESPONSE</BusinessConcept>  <!-- or HVP_FRAUD_RESPONSE_REJECT or HVP_FRAUD_RESPONSE_PENDING -->
      <RequestID>16858005</RequestID>
   </Header>
   <isf:Acknowledgement>
      <GeneralInformation>
         <CreationDateTime>2017-11-20T07:30:19</CreationDateTime>
      </GeneralInformation>
      <OriginalMessageStatusInformation>
         <TransactionStatusInformation>
            <TransactionIdentification>16858005</TransactionIdentification>
            <TransactionStatus>
               <StatusCode>ACTC</StatusCode>  <!-- or RJCT or PNDG -->
            </TransactionStatus>
         </TransactionStatusInformation>
      </OriginalMessageStatusInformation>
   </isf:Acknowledgement>
</isf:ISFMessage>
Note: This sample XML is only indicative of the document structure.
Model changes
  1. Create an appropriate FTM format in the customer application model. This format defines the format and structure of the response message that is expected from the fraud screening service.
  2. Copy the FTM mapper FraudScreeningResponseToISFMapper from the Common IP model into the customer application model. Modify the following properties:
    • Name
    • ID
    • Description
    • Format (select new format)
  3. Copy the FTM channel Fraud Screening Response from the Common IP model into the customer application model. Modify the following properties:
    • Format (select the new format)
    • Mapper (select the new mapper)
  4. Review the other properties, such as CCSID, validation, and transport, and change them as needed.
  5. Save and validate the changes.
  6. Extract and deploy a new config script.
Note: Due to a known issue in the FTM Configuration Data Extractor, the artifacts that were copied from the Common IP model need to be deleted from the Common IP model after they are copied.
Code changes
  1. Implement an IBM App Connect Enterprise message model to use with the new format that was defined in step 1 of the model changes. Or, import or select a suitable XML schema or other type of format descriptor to use with it.
  2. Implement a new inbound mapper by using a standard FTM mapping template or by copying an existing inbound mapper. Create the mapper in a customer-named application IBM App Connect Enterprise library. Ensure that the label of the mapper is changed to match the name that was assigned in step 2 of the model changes.
  3. Ensure that the mapper is added to the customer application physical transmission wrapper flow that is equivalent to PT_Wrapper_FraudResp.msgflow. Ensure that the Datasource property is promoted and connected to the Datasource property of the wrapper flow.
  4. Rebuild and deploy the new customer workspace.