Bank Transaction Data Analysis: Precision, Recall, and Account Matching

MI도 precision과 recall을 계산해야 하나요?

So, I should calculate the precision and recall rates for MI as well, right?

전에 슬라이드에 적어준 네 가지 분류에 대해서만 precision과 recall을 계산하면 되나요?

Do I only need to calculate precision and recall for the four categories you listed on the slide before?

그러면 MI는 Branch Teller만 하면 되나요?

So for MI, do I just need to do Branch Teller?

Branch Teller 거래가 모두 Draft 거래라고 확정된 건가요?

Has it been confirmed that all Branch Teller transactions are Draft transactions?

지금 말씀하시는 code가 TRXN_TYPE1_CD를 말하는 건가요?

Are you referring to TRXN_TYPE1_CD when you say "code"?

저는 account type과 business group을 매칭하는 작업을 하고 있습니다.

I'm working on matching the account type with the business group.

이제 WIRE를 하려고 합니다.

I'm about to work on WIRE.

WIRE에는 각 거래마다 두 개의 account ID가 있습니다.

WIRE has two account IDs for each transaction.

처리할 아이디어가 하나 있는데, 일단 해보고 되는지 봐야 할 것 같습니다.

I have an idea for how to handle it, but I think I need to try it first and see if it works.

그 외에는 blocker가 없습니다.

Other than that, I don't have any blockers.

Account type이 business group과 일치합니다.

The account type matches the business group.

저는 account type을 business group과 매칭하고 있습니다.

I'm matching the account type with the business group.

이 코드가 DAS mapping과 일치합니다.

This code matches the DAS mapping.

매치되는 것을 찾았습니다.

I found a match.

이 코드와 매치되는 것이 없습니다.

There was no match for this code.

Beneficiary account에는 IX, XA, null이 섞여 있습니다.

The beneficiary accounts are a mix of IX, XA, and null.

Debit 거래이기 때문에 origin account는 모두 IA입니다.

Since these are debit transactions, all origin accounts are IA.

Beneficiary account는 IX, XA 또는 null입니다.

The beneficiary accounts are either IX, XA, or null.

Account type이 null인 경우는 beneficiary account가 XA이거나 null인 경우입니다.

The account type is null when the beneficiary account is either XA or null.

이 income 거래들은 null 값의 개수와 non-null 값의 개수가 비슷합니다.

For these income transactions, the number of null values is similar to the number of non-null values.

모두 credit 거래이기 때문에 origin account는 대부분 XA이고 beneficiary account는 모두 IA입니다.

Since they're all credit transactions, most origin accounts are XA, while all beneficiary accounts are IA.

이것들은 모두 SQL에서 확인했습니다.

I checked all of these in SQL.

다른 코드들은 확인하지 않았습니다.

I didn't check the other codes.

비율이 비슷해 보여서 아마 같은 패턴을 따를 것 같습니다.

The ratios look similar, so I think they probably follow the same pattern.

이 코드는 account type이 MTY 또는 DAS입니다.

For this code, the account type can be either MTY or DAS.

제 기억이 맞다면 이 transaction code는 MTS2M에 속합니다.

If I remember correctly, this transaction code belongs to MTS2M.

이 거래는 Mastercard bill payment입니다.

It's a Mastercard bill payment.

거래의 주체는 카드 회사입니다.

The main entity is the card company.

Origin account에는 IA와 XA가 섞여 있습니다.

The origin accounts are a mix of IA and XA.

Beneficiary account는 모두 Mastercard 계좌입니다.

All the beneficiary accounts are Mastercard accounts.

Mastercard 입장에서는 credit 거래입니다.

From Mastercard's perspective, it's a credit transaction.

DAS와 null account type은 모두 origin side이고 거래 주체가 아닙니다.

DAS and null account types are on the origin side only and are not the transaction entity.

이 ID들은 TD account ID로 보입니다.

These IDs look like TD account IDs.

일부 ID는 account data에 없습니다.

Some of these IDs are not in the account data.

그런 경우에도 acct_type이 null입니다.

In those cases, the acct_type is also null.

우리가 보려는 것은 account type과 TRXN_TYPE1_CD가 속한 business group이 얼마나 잘 일치하는지입니다.

What we're trying to see is how well the account type matches the business group that the TRXN_TYPE1_CD belongs to.

WIRE 부분을 좀 작업했습니다.

I've done some work on the WIRE part.

공유하기 전에 먼저 너한테 확인받아야 할 것 같습니다.

I think I should confirm it with you before I share it.

각 거래마다 어떤 account를 사용할지 결정해야 합니다.

We need to decide which account to use for each transaction.

INIT_ROLE_CD를 기준으로 credit 거래에는 origin account를 사용하기로 했습니다.

Based on the INIT_ROLE_CD column, I decided to use the origin account for credit transactions.

Debit 거래에는 beneficiary account를 사용하기로 했습니다.

I decided to use the beneficiary account for debit transactions.

이것은 MI에서 acct_type과 CSTM_3_TX의 조합을 보여줍니다.

This shows the combinations of acct_type and CSTM_3_TX in MI.

DAS와 WDS의 경우 acct_type이 null이면 CSTM_3_TX를 사용할 수 있을 것 같습니다.

For DAS and WDS, I think we can use CSTM_3_TX when acct_type is null.

STA와 IMSB의 경우에는 CSTM_3_TX 값이 없습니다.

For STA and IMSB, there are no CSTM_3_TX values.

제가 CASH data만 보고 섣불리 판단했습니다.

I jumped to conclusions based only on the CASH data.

제가 CASH data만 보고 그렇게 추정했습니다.

I made that assumption based only on the CASH data.

CASH data만 보고 WIRE도 비슷할 거라고 생각했습니다.

I assumed WIRE would be similar based only on the CASH data.

WIRE는 더 복잡합니다.

WIRE is more complicated.

특히 WDS로 추정되는 부분이 더 복잡합니다.

It's more complicated, especially the part that seems to be WDS.

지금 mismatch가 있는 조합 몇 개를 확인하고 있습니다.

I'm checking some of the mismatched combinations.

DAS-MTY 조합 몇 개를 살펴보다가 이것을 알게 됐습니다.

Looking at some DAS-MTY combinations, I realized this.

acct_type과 CSTM_3_TX의 조합도 INIT_ROLE과 acct_side의 조합에 따라 달라질 수 있습니다.

The acct_type and CSTM_3_TX combination can also vary depending on the combination of INIT_ROLE and acct_side.

A와 B의 조합

The combination of A and B.

DAS-MTY 조합

The DAS-MTY combination.

Account type과 business group이 일치하지 않는 조합 몇 개를 보고 있습니다.

I'm looking at some combinations where the account type and business group don't match.

MI에서는 null 값이 많습니다.

In MI, there are many null values.

MI의 경우에는 CSTM_3_TX를 사용할 수 있습니다.

For MI, we can use CSTM_3_TX.

이 경우에는 CSTM_3_TX를 사용할 수 있습니다.

In this case, we can use CSTM_3_TX.

여기에서는 acct_type이 null입니다.

Here, the acct_type is null.

기존 로직을 보완했습니다.

I refined the existing logic.

이 두 접근법은 서로 보완합니다.

These two approaches complement each other.

일치하다

match

A가 B와 일치하다

A matches B

A와 B를 매칭하다

match A with B

일치 / 매치되는 것

a match

매칭된

matched

매칭되지 않은

unmatched

서로 일치하지 않는

mismatched

일치하지 않다

doesn't match

A와 B의 조합

the combination of A and B

A-B 조합

the A-B combination

여러 종류가 섞여 있다

be a mix of

A 또는 B 중 하나

either A or B

~에 따라서 달라지다

vary depending on

~라는 것을 알게 되다

realize that

~만을 근거로

based only on

섣불리 결론 내리다

jump to conclusions

~라고 추정하다

assume

가정 / 추정하다

make an assumption

제 기억이 맞다면

if I remember correctly

~의 입장에서

from ~'s perspective

~에 속하다

belong to

~을 가리키다 / ~을 말하다

refer to

~을 확인하다

check

~와 확인하다 / ~에게 확인받다

confirm with

되는지 확인해보다

see if it works

처리하다

handle

결정하다

decide

~하려는 중이다

be about to

그 외에는

other than that

방해 요소 / 업무 진행을 막는 문제

blocker

비율

ratio

비슷한 패턴을 따르다

follow a similar pattern

거래 주체

transaction entity

송금인

remitter

송금하다

remit

송금 / 송금액

remittance

수취인

beneficiary

송금하는 쪽

originator / remitter

~에서는

in ~