7Define Payments Security

This chapter contains the following:

Implement application security options on the Manage System Security Options page. You can set the application security to align with your company's security policy. You can set security options for encryption and tokenization of credit cards and bank accounts, as well as for masking the payment instrument. Both funds capture and disbursement processes use security options.

Note: Credit card services are currently not available in Oracle Financials Cloud.
Note: You must enable encryption or tokenization of credit cards in Payments before you can import credit cards into Expenses.

Ask yourself these security questions to improve the security of your sensitive data:

  • Which security practices do I want to employ?

  • Do I want to tokenize my credit card data?

  • Do I want to encrypt my bank account data?

  • Do I want to encrypt my credit card data?

  • How frequently do I want to rotate the master encryption key and the subkeys?

  • Do I want to mask credit card and bank account numbers? How do I accomplish that?

To set up application security options, go to Financials > Payments > Manage System Security Options in the Setup and Maintenance work area.

Best Security Practices

These actions are considered best security practices for payment processing:

  • Comply with the Payment Card Industry Data Security Standard (PCI DSS). PCI DSS is the security standard required for processing most types of credit cards.

    • Comply with all requirements for accepting credit card payments.

    • Minimize the risk of exposing sensitive customer data.

  • Create the master encryption key.

    • Rotate the master encryption key periodically.

Implementation Process of Master Encryption Key and Encryption

Before you can enable encryption for credit card or bank account data, you must automatically create a master encryption key. Oracle Platform Security Services stores your master encryption key. The application uses your master encryption key to encrypt your sensitive data.

Automatic creation of the master encryption key ensures that it's created and stored in the proper location and with all necessary permissions.

Credit Card Tokenization

If you tokenize your credit card data, you're complying with PCI DSS requirements. PCI DSS requires companies to use payment applications that are PCI DSS compliant.

Tokenization is the process of replacing sensitive data, such as credit card data, with a unique number, or token, that isn't considered sensitive. The process uses a third-party payment system that stores the sensitive information and generates tokens to replace sensitive data in the applications and database fields. Unlike encryption, tokens can't be mathematically reversed to derive the actual credit card number.

Click Edit Tokenization Payment System on the Manage System Security Options page to set up your tokenization payment system. Then, click Tokenize in the Credit Card Data section to activate tokenization for credit card data.

Credit Card Data Encryption

You can encrypt your credit card data to assist with your compliance of cardholder data protection requirements with these initiatives:

  • Payment Card Industry Data Security Standard

  • Visa's Cardholder Information Security Program

Credit card numbers entered in Oracle Receivables and Oracle Collections are automatically encrypted. Encryption is based on the credit card encryption setting you specify on the Manage System Security Options page.

Note: If you import card numbers into Payments, you should run the Encrypt Credit Card Data program immediately afterward.

Bank Account Data Encryption

You can encrypt your supplier and customer bank account numbers.

Bank account encryption doesn't affect internal bank account numbers. Internal bank accounts are set up in Cash Management. They are used as disbursement bank accounts in Payables and as remit-to bank accounts in Receivables.

Supplier, customer, and employee bank account numbers entered in Oracle applications are automatically encrypted. Encryption is based on the bank account encryption setting you specify on the Manage System Security Options page.

Note: If you import bank account numbers into Payments, you should run the Encrypt Bank Account Data program immediately afterward.

Master Encryption Key and Subkey Rotation

For payment instrument encryption, Payments uses a chain key approach. The chain key approach is used for data security where A encrypts B and B encrypts C. In Payments, the master encryption key encrypts the subkeys and the subkeys encrypt the payment instrument data. This approach enables easier rotation of the master encryption key.

The master encryption key is stored on Oracle Platform Security Services. Oracle Platform Security Services stores data in an encrypted format. The master encryption key can be rotated, or generated, which also encrypts subkeys, but doesn't result in encrypting the bank account numbers again.

If your installation has an existing master encryption key, click Rotate to automatically generate a new one.

Note: To secure your payment instrument data, you should rotate the master encryption key annually or according to your company's security policy.

You can also select the frequency with which new subkeys are automatically generated, based on usage or on the maximum number of days. To specify a subkey rotation policy, click Edit Subkey Rotation Policy.

Note: To secure your payment instrument data, you're advised to schedule regular rotation of the subkeys.

The security architecture for credit card data and bank account data encryption is composed of these components:

  • Oracle Platform Security Services

  • Payments master encryption key

  • Payments subkeys

  • Sensitive data encryption and storage

This figure illustrates the security architecture of the Oracle Platform Security Services repository, the master encryption key, and the subkeys.

This figure illustrates the security architecture
of Oracle Platform Security Services, the master encryption key, and
the subkeys.

Credit Card and Bank Account Number Masking

Payments serves as a payment data repository for customer and supplier information. It stores all of the customer and supplier payment information and their payment instruments, such as credit cards and bank accounts. It provides data security by letting you mask bank account numbers.

On the Manage System Security Options page, you can mask credit card numbers and external bank account numbers. You just have to select the number of digits to mask and display. For example, a bank account number of XXXX8012 displays the last four digits and masks all the rest. These settings specify masking for payment instrument numbers in the user interfaces of multiple applications.

Note: Credit cards can only have up to the last 4 digits displayed and external bank accounts can have up to the last six digits displayed. Also for both credit cards and bank accounts, up to the first 6 digits can be set for viewing, for example, 123456XXXXX.

Financial transactions contain sensitive information, which must be protected by a secure, encrypted mode. To protect your credit card and external bank account information, you can enable encryption. Encryption encodes sensitive data, so it can't be read or copied. To enable encryption, you must create a master encryption key. Oracle Platform Security Services is a repository that stores your master encryption key. The application uses your master encryption key to encrypt your sensitive data.

Note: Before you can import credit cards into Expenses, you must enable encryption or tokenization of credit cards in Payments. If you're using credit card data anywhere other than Expenses, you must enable tokenization in Payments.

To secure your credit card or bank account data, complete these steps:

  1. In the Setup and Maintenance work area, go to Financials > Payments > Manage System Security Options.

  2. On the Manage System Security Options page, click Apply Quick Defaults.

  3. Select all the check boxes:

    • Automatically create wallet file and master encryption key

    • Encrypt credit card data

    • Encrypt bank account data

  4. Click Save and Close.

Credit card tokenization is the process of replacing sensitive data with a unique surrogate number, or token, that is not considered sensitive. The process employs services of a third-party token service provider that stores the sensitive information and generates tokens to replace sensitive data in the applications and in database fields.

Note: Credit card services are currently not available in Oracle Financials Cloud implementations.
Note: Before you can import credit cards into Expenses, you must enable encryption or tokenization of credit cards in Payments.

To enable credit card tokenization, you perform steps in the following setup pages:

  • Manage System Security Options page

  • Create Payment System page

Manage System Security Options

To enable credit card tokenization on the Manage System Security Options page, click Edit Tokenization Payment System. Select CyberSource as the tokenization payment system. Now you can view CyberSource as the read-only tokenization payment system in the Tokenization section.

Create Payment System

To enable credit card tokenization on the Create Payment System page, follow these steps:

  1. In the Tokenization Payment System Settings subsection, select the Credit card tokenization check box.

  2. In the Tokenization Payment System Settings section, enter values that relate to the following fields:

    • Name

    • Code

    • Data Type

    • Secured: Specify Yes or No.

    • Value

Note: The tokenization settings are already predefined for the CyberSource payment system. You only need to enter the values.

How Imported Legacy Credit Cards Are Processed

Use the Import Legacy Credit Cards process to import tokenized legacy credit cards data into Oracle Payments Cloud from legacy and external sources through a batch, flat file-based interface. You can download a spreadsheet template to enter your legacy credit cards data. The spreadsheet template conveniently provides field-level bubble help for assistance.

Caution: Before you can import legacy credit card numbers into Payments, you must ensure that they are tokenized to maintain strict compliance with the PCI (Payment Card Industry) rules protecting Oracle Applications Cloud from audit.

This figure illustrates the flow of importing legacy credit cards data into the application, as well as correcting errors.

This figure illustrates the flow of importing legacy
credit cards data into the application, as well as correcting errors.

To access the IbyLegacyCreditCardsImportTemplate.xlsm spreadsheet template, complete these steps:

  1. Navigate to the File-Based Data Import for Oracle Financials Cloud guide.

  2. In the Table of Contents, click the File-Based Data Imports link.

  3. Click the Import Legacy Credit Cards link.

  4. In the File Links section, click the link to the Excel template.

Before you can import legacy credit cards data, you must complete these steps:

  1. Enable tokenization in Payments.

  2. Configure at least one payment system with tokenization enabled. The tokenization service provider is CyberSource.

  3. Configure the ORA_IBY_DTK_RUN lookup that enables the Import Legacy Credit Cards program.

  4. Tokenize the legacy credit cards data using a batch file upload process in CyberSource.

Follow these guidelines when preparing your data in the spreadsheet template:

  • Enter the required information for each column. Refer to tool tips on each column header for the expected data type or for detailed instructions.

  • Don't change the order of the columns in the spreadsheet template.

    If you change the order of the columns, the upload process fails.

  • You can hide or skip columns you don't use, but don't delete them.

    If you delete columns, the upload process fails.

Spreadsheet Tabs that Affect the Import Legacy Credit Cards Process

The following table contains the name of the spreadsheet tabs in the Legacy Credit Cards Import spreadsheet template and a brief description of their content.

Spreadsheet Tab Description

Instructions and CSV Generation

  • Overview of the process

  • CSV generation button

  • Revision history

Tokenized Credit Card Details

Column headings for entering tokenized card details

How Import Legacy Credit Cards Data Is Processed

The following table describes the flow of data when you import tokenized legacy credit cards into Payments.

Sequence Action Result

1

From the guide titled File-Based Data Import for Oracle Financials Cloud, download the spreadsheet template named IbyLegacyCreditCardsImportTemplate.xlsm. It is located in the File-Based Data Imports chapter, Legacy Credit Cards Import section.

The file-based data import spreadsheet template is downloaded.

2

  1. Enter data in the spreadsheet template.

  2. Refer to the bubble text on each column header either for detailed instructions on entering the data in that column, or for a description of the data and data type that the column requires.

  3. Don't delete row number 5, which shows text in capital letters.

  4. Each credit card is assigned to the customer at the customer account or customer account site use level.

The spreadsheet template is ready for CSV file generation.

3

  1. Click Generate CSV File.

  2. Save the CSV file with a unique name.

A CSV file is generated that is compressed into a ZIP file.

4

To upload the ZIP file to Oracle Universal Content Management:

  1. Navigate: Tools > File Import and Export.

  2. On the File Import and Export page, click the plus (Upload) icon. The Upload File dialog box appears.

  3. In the File field, browse for and select your ZIP file.

  4. From the Account choice list, select fin/payments/import.

  5. Click Save and Close.

The ZIP file is uploaded.

5

To submit the Import Legacy Credit Cards process:

  1. Sign in to the central Oracle Enterprise Scheduler server.

  2. Navigate: Tools > Scheduled Processes.

  3. Click Schedule New Process.

    The Schedule New Process dialog box appears.

  4. From the Name choice list, search and select Tokenize Credit Card Data.

  5. Click OK.

    The Process Details dialog box appears.

  6. From the Credit Card Data Import File choice list, select your ZIP file.

  7. Click Submit.

The Import Legacy Credit Cards process first validates the credit cards and associated data and then imports the data from the uploaded file into the following Payments tables:

  • IBY_CREDITCARD

  • IBY_PMT_INSTR_USES_ALL

After you submit the Import Legacy Credit Cards process, the following data appears in Payments:

  • Credit card data

  • Assignment data

The log output of the Import Legacy Credit Cards process reports the number of successful and rejected records.

6

To correct import errors:

  1. View the log output from the Import Legacy Credit Cards process.

  2. Identify the rejected records based on details provided in the log file.

  3. Create a new spreadsheet that contains only rejected records that you copy from the old spreadsheet template.

  4. For the Origin Site Purpose Source Reference column, enter a different unique value.

  5. Make necessary corrections to the data.

  6. Load the data using a new spreadsheet.

  7. Generate the CSV File, upload the ZIP file, and continue.

Failed records are visible in the log output from the Import Legacy Credit Cards process. A new spreadsheet that contains only corrected records is uploaded and processed again.

7

Import legacy credit cards data at one of the following levels if you have their associated identifiers:

  • Customer account

  • Customer account site

In the spreadsheet, if the Owner Level column is CUST_ACCOUNT, then credit cards are assigned at the customer account level.

In the spreadsheet, if the Owner Level column is CUST_ACCT_SITE_USE, then credit cards are assigned at the customer account site level.

Removal of Personally Identifiable Information

The General Data Protection Regulation is a regulation in European Union (EU) law about data protection and privacy for all individuals within the EU and the European Economic Area. Your organization can comply with the GDPR regarding the collection and use of personal data of EU residents.

You can remove an individual's personal data:

  • If requested by an individual

  • If the individual is no longer employed with your organization

Caution: If you remove personally identifiable information, it can't be retrieved.

To run the removal process, you must have the duty role of Financial Application Administrator.

To remove an individual's personally identifiable information for any product in Oracle Financials applications, you submit the Remove Personally Identifiable Information in Financials process.

  1. Navigate: Navigator > Tools > Scheduled Processes.

  2. On the Scheduled Processes page, click Schedule New Process.

  3. Search and select Remove Personally Identifiable Information in Financials.

  4. From the Party choice list, select the person's name for whom you want to remove personally identifiable information.

  5. Click Submit.

Table and Column Details for Potential Removal of Personally Identifiable Information

This table lists applications and their corresponding tables and columns that store sensitive data, the data type that is stored in each column, whether you can redact the data from the column, and the reason for redaction.

Sequence Number and Product Table Column Data Type Redact? Reason for Redaction

1

Oracle Payments

IBY_CREDITCARD

CC_NUMBER_HASH1

VARCHAR2(64 CHAR)

No

Unreadable data.

2

Oracle Payments

IBY_CREDITCARD

CC_NUMBER_HASH2

VARCHAR2(64 CHAR)

No

Unreadable data.

3

Oracle Payments

IBY_CREDITCARD

CCNUMBER

VARCHAR2(30 CHAR)

No

Tokenized or encrypted data.

4

Oracle Payments

IBY_CREDITCARD

CHNAME

VARCHAR2(80 CHAR)

No

Nonsensitive since card is secured.

5

Oracle Payments

IBY_CREDITCARD

EXPIRYDATE

DATE

No

Nonsensitive since card is secured.

6

Oracle Payments

IBY_CREDITCARD

MASKED_CC_NUMBER

VARCHAR2(30 CHAR)

No

Nonsensitive since card is secured.

7

Oracle Payments

IBY_EXT_BANK_ACCOUNTS

BANK_ACCOUNT_NAME

VARCHAR2(80 CHAR)

Yes

Sensitive data.

8

Oracle Payments

IBY_EXT_BANK_ACCOUNTS

BANK_ACCOUNT_NAME_ALT

VARCHAR2(320 CHAR)

Yes

Sensitive data.

9

Oracle Payments

IBY_EXT_BANK_ACCOUNTS

BANK_ACCOUNT_NUM

VARCHAR2(100 CHAR)

Yes

Sensitive when bank account isn't encrypted or masked.

10

Oracle Payments

IBY_EXT_BANK_ACCOUNTS

BANK_ACCOUNT_NUM_ELECTRONIC

VARCHAR2(100 CHAR)

Yes

Sensitive when bank account isn't encrypted or masked.

11

Oracle Payments

IBY_EXT_BANK_ACCOUNTS

BANK_ACCOUNT_NUM_HASH1

VARCHAR2(64 CHAR)

No

Unreadable data.

12

Oracle Payments

IBY_EXT_BANK_ACCOUNTS

BANK_ACCOUNT_NUM_HASH2

VARCHAR2(64 CHAR)

No

Unreadable data.

13

Oracle Payments

IBY_EXT_BANK_ACCOUNTS

IBAN

VARCHAR2(50 CHAR)

Yes

Sensitive when bank account isn't encrypted or masked.

14

Oracle Payments

IBY_EXT_BANK_ACCOUNTS

IBAN_HASH1

VARCHAR2(64 CHAR)

No

Unreadable data.

15

Oracle Payments

IBY_EXT_BANK_ACCOUNTS

IBAN_HASH2

VARCHAR2(64 CHAR)

No

Unreadable data.

16

Oracle Payments

IBY_EXT_BANK_ACCOUNTS

MASKED_BANK_ACCOUNT_NUM

VARCHAR2(100 CHAR)

Yes

Denormalized value. Sensitive when bank account isn't encrypted or masked.

17

Oracle Payments

IBY_EXT_BANK_ACCOUNTS

MASKED_IBAN

VARCHAR2(50 CHAR)

Yes

Denormalized value. Sensitive when bank account isn't encrypted or masked.

18

Oracle Payments

IBY_FNDCPT_TX_EXTENSIONS

INSTRUMENT_SECURITY_CODE

VARCHAR2(10 CHAR)

No

No longer store card verification value.

19

Oracle Payments

IBY_TRXN_SUMMARIES_ALL

DEBIT_ADVICE_EMAIL

VARCHAR2(255 CHAR)

Yes

Denormalized value. Sensitive data.

20

Oracle Payments

IBY_PAYMENTS_ALL

EXT_BANK_ACCOUNT_NAME

VARCHAR2(360 CHAR)

Yes

Nonsensitive when person data is redacted.

21

Oracle Payments

IBY_PAYMENTS_ALL

EXT_BANK_ACCOUNT_NUMBER

VARCHAR2(100 CHAR)

Yes

Denormalized value. Sensitive when bank account isn't encrypted or masked.

22

Oracle Payments

IBY_PAYMENTS_ALL

EXT_BANK_ACCOUNT_IBAN_NUMBER

VARCHAR2(50 CHAR)

Yes

Denormalized value. Sensitive when bank account isn't encrypted or masked.

23

Oracle Payments

IBY_PAYMENTS_ALL

PAYEE_NAME

VARCHAR2(360 CHAR)

Yes

Payee name is sensitive data.

24

Oracle Payments

IBY_PAYMENTS_ALL

PAYEE_ADDRESS1

VARCHAR2(240 CHAR)

Yes

Address data.

25

Oracle Payments

IBY_PAYMENTS_ALL

PAYEE_ADDRESS2

VARCHAR2(240 CHAR)

Yes

Address data.

26

Oracle Payments

IBY_PAYMENTS_ALL

PAYEE_ADDRESS3

VARCHAR2(240 CHAR)

Yes

Address data.

27

Oracle Payments

IBY_PAYMENTS_ALL

PAYEE_ADDRESS4

VARCHAR2(240 CHAR)

Yes

Address data.

28

Oracle Payments

IBY_PAYMENTS_ALL

PAYEE_CITY

VARCHAR2(60 CHAR)

Yes

Address data.

29

Oracle Payments

IBY_PAYMENTS_ALL

PAYEE_POSTAL_CODE

VARCHAR2(60 CHAR)

Yes

Address data.

30

Oracle Payments

IBY_PAYMENTS_ALL

PAYEE_STATE

VARCHAR2(120 CHAR)

Yes

Address data.

31

Oracle Payments

IBY_PAYMENTS_ALL

PAYEE_PROVINCE

VARCHAR2(120 CHAR)

Yes

Address data.

32

Oracle Payments

IBY_PAYMENTS_ALL

PAYEE_COUNTY

VARCHAR2(120 CHAR)

Yes

Address data.

33

Oracle Payments

IBY_PAYMENTS_ALL

PAYEE_COUNTRY

VARCHAR2(60 CHAR)

Yes

Address data.

34

Oracle Payments

IBY_PAYMENTS_ALL

REMIT_ADVICE_EMAIL

VARCHAR2(255 CHAR)

Yes

Address data.

35

Oracle Payments

IBY_PAYMENTS_ALL

PAYEE_PARTY_NAME

VARCHAR2(360 CHAR)

Yes

Party name is sensitive data.

36

Oracle Payments

IBY_PAYMENTS_ALL

PAYEE_LE_REGISTRATION_NUM

VARCHAR2 (50 CHAR)

Yes

Denormalized value. Sensitive data.

37

Oracle Payments

IBY_PAYMENTS_ALL

PAYEE_TAX_REGISTRATION_NUM

VARCHAR2 (50 CHAR)

Yes

Denormalized value. Sensitive data.

38

Oracle Payments

IBY_PAYMENTS_ALL

PAYEE_ADDRESS_CONCAT

VARCHAR2 (2000 CHAR)

Yes

Address data.

39

Oracle Payments

IBY_PAYMENTS_ALL

BENEFICIARY_NAME

VARCHAR2 (360 CHAR)

Yes

Beneficiary name is sensitive data.

40

Oracle Payments

IBY_PAYMENTS_ALL

PAYEE_ALTERNATE_NAME

VARCHAR2 (360 CHAR)

Yes

Payee alternate name is sensitive data.

41

Oracle Payments

IBY_PAYMENTS_ALL

EXT_BANK_ACCOUNT_ALT_NAME

VARCHAR2 (320 CHAR)

Yes

Bank account alternate name is sensitive data.

42

Oracle Payments

IBY_PAYMENTS_ALL

EXT_BANK_ACCOUNT_NUM_ELEC

VARCHAR2 (100 CHAR)

Yes

Denormalized value. Sensitive when bank account isn't encrypted or masked.

43

Oracle Payments

IBY_PAYMENTS_ALL

EXT_BANK_ACCT_OWNER_PARTY_NAME

VARCHAR2 (360 CHAR)

Yes

Owner party name is sensitive data.

44

Oracle Payments

IBY_EXTERNAL_PAYEES_ALL

REMIT_ADVICE_EMAIL

VARCHAR2(255 CHAR)

Yes

Sensitive data.

45

Oracle Payments

IBY_EXTERNAL_PAYERS_ALL

DEBIT_ADVICE_EMAIL

VARCHAR2(255 CHAR)

Yes

Sensitive data.

46

Oracle Payables

AP_CHECKS_ALL

ADDRESS_LINE1

VARCHAR2(240 CHAR)

Yes

Address data.

47

Oracle Payables

AP_CHECKS_ALL

ADDRESS_LINE2

VARCHAR2(240 CHAR)

Yes

Address data.

48

Oracle Payables

AP_CHECKS_ALL

ADDRESS_LINE3

VARCHAR2(240 CHAR)

Yes

Address data.

49

Oracle Payables

AP_CHECKS_ALL

CITY

VARCHAR2(60 CHAR)

Yes

Address data.

50

Oracle Payables

AP_CHECKS_ALL

COUNTRY

VARCHAR2(60 CHAR)

Yes

Address data.

51

Oracle Payables

AP_CHECKS_ALL

ZIP

VARCHAR2(60 CHAR)

Yes

Address data.

52

Oracle Payables

AP_CHECKS_ALL

VENDOR_NAME

VARCHAR2(240 CHAR)

Yes

Supplier name is sensitive data.

53

Oracle Payables

AP_CHECKS_ALL

BANK_ACCOUNT_NUM

VARCHAR2(30 CHAR)

Yes

Denormalized value.

54

Oracle Payables

AP_CHECKS_ALL

ADDRESS_LINE4

VARCHAR2(240 CHAR)

Yes

Address data.

55

Oracle Payables

AP_CHECKS_ALL

COUNTY

VARCHAR2(150 CHAR)

Yes

Address data.

56

Oracle Payables

AP_CHECKS_ALL

IBAN_NUMBER

VARCHAR2(40 CHAR)

Yes

Denormalized value.

57

Oracle Cash Management

CE_PAYEES

TAX_REGISTRATION_NUMBER

VARCHAR2(20 CHAR)

Yes

Sensitive data.

58

Oracle Receivables

AR_CUSTOMER_ALT_NAMES

ALT_NAME

VARCHAR2(320 CHAR)

Yes

Alternate customer name using Zengin characters.

59

Oracle Receivables

AR_PAYMENT_SCHEDULES_ALL

DEL_CONTACT_EMAIL_ADDRESS

VARCHAR2(1000 CHAR)

Yes

Email of the customer bill-to contact who receives printed transactions.

60

Oracle Receivables

RA_CUSTOMER_TRX_ALL

DEL_CONTACT_EMAIL_ADDRESS

VARCHAR2(1000 CHAR)

Yes

Email of the customer bill-to contact who receives printed transactions.

61

Oracle Advanced Collections

IEX_DUNNINGS

CONTACT_DESTINATION

VARCHAR2(240 CHAR)

Yes

Contact who receives the dunning.